Would be smarter, less effort and maybe remove or change the spam vector if the process were this (myself being the developer):<p>1. Visit site. Enter my email address and maybe client name. It gives me a unique URL (supportdetails.com/jasd9s89ajd698/ or optionally support.mybusiness.com/clientname).<p>2. I email that to the client and tell them to click the link. [Risk of training them to click strange links...]<p>3. They visit the page and get a Thanks message. It automatically sends me all the info I need.<p>Burden on the client is lowered. First time I saw this site or similar (been around for years) I wondered about quickly building an alternative that offered white labeling and the above process instead. Easy weekend project for someone, I imagine.
I just spammed some guys by using this site. You may want to at least do a CAPTCHA. You or your ISP may receive complaints or get blacklisted if you're not careful.<p>Update: I also forged/made-up the from email address. Could have fun on an open wifi network with this. I suggest you stop, and think about all the ways this could be abused (and how you can prevent that) before proceeding.<p>Update2: The eamil "from header" actually has the forged address in it so if the recipient victim replies, the reply goes to the sender victim. Nice. The real culprit is clearly identified though:<p>X-Originating-IP: 173.193.132.135<p>Received: from heroku.com (unknown [10.9.180.5])<p>Update3: Sergey Brin is about to send an email to Zuck ;) just kidding.
Hey everyone. Taylor from Imulus here. I'm the front-end developer leading up Support Details.<p>Thanks for all of the positive and constructive comments. We're really excited to take Support Details to the next level, and based on your comments, I think our ideas on the right track. As of late, we've been focusing on the accuracy and speed of the site (see <a href="http://imulus.com/blog/bryce/javascript/support-details-on-rails/" rel="nofollow">http://imulus.com/blog/bryce/javascript/support-details-on-r...</a>), but now that we've got that nailed down, we're excited to start rolling out some new features.<p>As an agency focused on client work, we've struggled in the past to make time for our own products, but we're set on making them a priority this year, so thanks again for the positive comments to encourage us to move forward.
You should seriously consider licensing this out to people. I would definitely pay 5 bucks a month to get this embedded on my own site. Either let them embed the script and you handle the data, or host a subdomain of their choosing, like "support.(their domain).com" because I'm sure a lot of people prefer to keep their customers within their own site. Makes customers feel much safer.
Is this your site?<p>I like the concept, but one suggestion. The rounded rectangles with the computers specs look like buttons. The onhover effect doesnt help either. I tried clicking for 5-10 secs before realizing they werent buttons.
Would love to see this go one step further. I can't get people to read details back to me or they want to read every single word very slowly from the top of the page. I want to use this to send them an email with a clickable link, they click, and I get an email back with all of these details -- nothing lost in translation. Network information would be great, too.
My suggestion would be as follows:
1. Partner registers a callback URL with you, gets an api_key and a shared secret in return.<p>2. When partner sends a user to your site, they make a call to <a href="http://supportdetails.com/<api_key>?data=<random" rel="nofollow">http://supportdetails.com/<api_key>?data=<random</a> base64 string><p>3. You collect details, and make a POST to the <callback_url> with all the information (including <random base64 string>) as JSON or XML and signed using a HMAC of the data with the shared secret<p>4. Partner verifies signature and then accepts the data. The <random base64 string> could contain information that the partner can use to identify the user/store session info, etc.<p>This protects your partners from fake submissions, if they care about that sort of thing.
I am definitely missing something here. So, this is what I understand - users can send the client side info to webmasters. But how do I get to know that email id? Ain't that the only reason why services like UserVoice or WebEngage exist? All these services automatically capture the client side info (most of the info that is presented on SupportDetails) everytime someone submits a feedback on their corresponding websites.<p>Disclaimer: I co-founded WebEngage (<a href="http://webengage.com" rel="nofollow">http://webengage.com</a>). And here's a shamless plug - WebEngage not only provides you all this client side info, it also captures a screenshot of the current page (on your website) the visitor is on.
A branded landing page makes sense. IE. I sign up with my company email, you give me a /url123 page, I forward that to my customers/users. They see it and simply fill their email and click "Send".
Doesn't work for my email account either. It would be a great thing to package up as a .js file to offer in support forms as something auto uploaded in a hidden part of the form.
Nice idea.<p>Why do you include the IP address? This seems like the only bit of personal, identifying information, as opposed to information that could affect the rendering of a site.<p>You seem to parse any version of Linux as an unknown OS with version "Linux", rather than the OS "Linux" with an unknown version.<p>You should include the full browser User-Agent string, not just the parsed-out bits; among other things, that provides the version of Gecko or WebKit, not just the version of the browser UI.
Ideas:<p>* Speed testing and connectivity testing.<p>* Throw in reverse DNS data for getting info on their ISP.<p>* Add ad-blocker detection.<p>* Add silverlight detection.
Export as PDF option might be a bit sketchy. You can inject whatever you want into the URL and it'll end up in the PDF. Not sure if it's sanitized (I am not familiar with the PDF file format) but if not, this could lead to exploitation.<p>Of course it wouldn't be on a grand scale necessarily, but as they say in several contexts, "a hole is a hole."
All of this is easy to auto-detect in Javascript that you can have on your support submit form--so this page is not that useful.<p>What is KILLER useful is <a href="http://showmewhatswrong.com" rel="nofollow">http://showmewhatswrong.com</a>. Instant screencasts from users of what is going wrong.
You should also send the HTML5 features supported by the browser via modernizr or something. Very easy to implement on your end and will be a huge timesaver in debugging javascript.
this is exactly what I need to debug a problem of some users in some versions of windows with our html5 video player, very good idea that solves a painful problem, keep it up!