As someone who uses these services in my job, I like the design a lot. A simple url and a simple copy button is great for these things (anyone who has done support will know what I'm talking about).
However, I get more information from whatsmybrowser.com
If someone could do a site that gives as much info as possible, including an Internet speed tests, I think it could become very popular.
"Google Chrome is generally considered the leader in supporting modern web standards, and can reliably handle most modern websites. It is also one of the fastest and most secure. "
Interesting, because it does the opposite for me, i.e. it reports my primary monitor's resolution, despite the browser running on my secondary monitor!
IP address and GeoIP is pretty handy from a support perspective, plus anything such as ISP that can be inferred from IP address. The whatismybrowser.com has IP address but not the GeoIP.
More generally an embeddable 'contact us' form for people to use might be useful if it solves problems of having to setup captcha, email and so on that is hard to do correctly. On the back of the contact us form there could be all the useful support gubbins so that whomever is in support dealing with the 'complaint' sent on on the contact us does not have to ask the customer to go to some third party site to find out the browser/IP/screen size and so on.
From what I can see, the issue is fixed now. But simply, someone put html in their useragent, the site copied it as text, and included it as text in the html. The browser then interpreted it as html, and executed the javascript.
The fix is to parse inputs, and replace < and > with html entities. You can see this fix if you read the source for the page.
This reminds me, have any of you guys run into the "dark side" of frequent browser updates? Couple months ago I file a support ticket on a website, they come back and say "I see you are using Chrome 33 and Firefox 24, we only support Chrome 27 and Firefox 19, please install those versions".
(Those were not the precise versions, but you get the idea)
I realise this is to assist with support, but why would anyone other than the owner of this site use it when they could just pull the user agent from their own logs when/if there's a need?
Every webapp I've ever written logs user agent in the audit trail because that's often useful both in support and detecting unwanted stuff. I'd have to assume that's a fairly common practise.
Barring an obvious use case I'm missing, it feels like a poorly written version of www.mybrowserinfo.com dressed up the theme de jour, minus the detail.
Them: "When I click the button, the menu shows up. But it disappears as soon as I hover over it"
Me: What's your username?
Them: jdoe@somehost.com
$ mysql -e "SELECT useragent FROM login_audit WHERE user = 'jdoe@somehost.com'"
+---------------------------------------------------+
| useragent |
+---------------------------------------------------+
| Mozilla/1.22 (compatible; MSIE 2.0; Windows 3.1) |
+---------------------------------------------------+
Me: thumping noises on wood
Them: Yes?
$ mysql -e "DELETE FROM users WHERE user = 'jdoe@somehost.com'"
Me: Problem resolved, goodbye.
(Admittedly this is probably why they don't let me do support, but the point remains, it's trivial and you should have this info.)
> What about someone who can't log in using a browser which is not their usual?
You're assuming a couple things about our hypothetical login_audit table, neither of which are neccesarily true and both of which would make our audit table functionally as useless (at least to me) as the OP's site
* That we only store the last useragent
* Only successful logins are recorded
In the latter case, I probably needn't (but I will) point out that failure to make any entry in the table would imply more serious connectivity issues being afoot.
I'd argue as your visitors scale, so should the ability to trace individual requests, and as your user-level support team scales, so do the tools you use to support them.
Another nice benefit is that building out a quick internal tool can be a great afternoon hack to clear your mind. It doesn't have to be good, just something to remove some pain.
We're tagging pretty much every request & correlating it with a user, and are able to pull logs pretty quickly. It's not hands-off, but we've built tooling to make it pretty straightforward to dig whats up.
Konqueror has been at major version 4 for the past 7 years or so. Also, these operating systems are called "FreeBSD" and "Linux". "amd64" or "x86_64" is the arch they're running on here.
I thought the purpose of the app was to demonstrate an intelligent parsing of the browser signature. After all, the user agent only tells part of the story.
Support. I work Support and Maintenance in an web agency and if I a client client calls up with an issue that I can't reproduce, the first question is what browser they use. There are a lot of inconsistencies between browsers and knowing it gives me one less thing to test with when I'm working on the issue.
Although I agree with other comments in this thread, that this is something your app should log, there are scenarios in which this type of tool is really useful. Namely: Registration/Sign-in errors, in which it's going to be extremely difficult to identify from log files which tuple relates to the user having issues.
You're right - every user action / step is hard for support.
We tackled this problem with Usersnap (https://usersnap.com ) - devs will get accurate information (Browser + OS version and a screenshot) directly with the bug report!
Have you considered generating a unique URL for the requester (technical support) to share with the client, maybe with their name ini t? Once they visit it, pull their details, store it, and email it to the requester, or add it in their account.
82 comments
[ 2.5 ms ] story [ 161 ms ] threadMemorable url, shows ip address, shows user agent, and much more. As an added bonus, if you:
It responds with just your external ip address.However, I get more information from whatsmybrowser.com
If someone could do a site that gives as much info as possible, including an Internet speed tests, I think it could become very popular.
> Share this now with your support team now!
I'm guessing it's because of the "trident" and "7.0" in the user agent: Mozilla/5.0 (Windows NT 6.3; Trident/7.0; Touch; rv:11.0) like Gecko
I've noticed a ton of sites that misdetect IE in this way. MS's attempt to 'improve' their UA string seems to have done more harm than good.
http://gs.statcounter.com/detect
Can you check if that detects your IE11 correctly?
It doesn't detect LightSpark as a Flash version.
"Google Chrome is generally considered the leader in supporting modern web standards, and can reliably handle most modern websites. It is also one of the fastest and most secure. "
More generally an embeddable 'contact us' form for people to use might be useful if it solves problems of having to setup captcha, email and so on that is hard to do correctly. On the back of the contact us form there could be all the useful support gubbins so that whomever is in support dealing with the 'complaint' sent on on the contact us does not have to ask the customer to go to some third party site to find out the browser/IP/screen size and so on.
http://www.whatsmybrowser.org/b/STOW3UD
Also the site completely breaks if I add rare unicodes at the end of the user agent:
🐧
(I honestly don't know and would love to learn about this. Thanks)
The fix is to parse inputs, and replace < and > with html entities. You can see this fix if you read the source for the page.
[http://whatsmybrowser.org/b/4DNMRK6]
(Those were not the precise versions, but you get the idea)
Every webapp I've ever written logs user agent in the audit trail because that's often useful both in support and detecting unwanted stuff. I'd have to assume that's a fairly common practise.
Barring an obvious use case I'm missing, it feels like a poorly written version of www.mybrowserinfo.com dressed up the theme de jour, minus the detail.
Them: "When I click the button, the menu shows up. But it disappears as soon as I hover over it.
Me: "What browser do you have?"
Them: "Google, I think."
Me: "Let's make sure. Could you go to whatbrowser.org and tell me what it says?"
Much simpler than having to fish through logs.
Me: What's your username?
Them: jdoe@somehost.com
Me: thumping noises on woodThem: Yes?
Me: Problem resolved, goodbye.(Admittedly this is probably why they don't let me do support, but the point remains, it's trivial and you should have this info.)
You're assuming a couple things about our hypothetical login_audit table, neither of which are neccesarily true and both of which would make our audit table functionally as useless (at least to me) as the OP's site
In the latter case, I probably needn't (but I will) point out that failure to make any entry in the table would imply more serious connectivity issues being afoot.In my own case the clients have multiple users using one account so you can never be sure who's user agent in the logs corresponds to what.
And once you reach a certain size the person doing user-level support very likely doesn't have access to server logs.
Another nice benefit is that building out a quick internal tool can be a great afternoon hack to clear your mind. It doesn't have to be good, just something to remove some pain.
We're tagging pretty much every request & correlating it with a user, and are able to pull logs pretty quickly. It's not hands-off, but we've built tooling to make it pretty straightforward to dig whats up.
http://www.quirksmode.org/blog/archives/2012/06/devicepixelr...
Midori as Safari: http://whatsmybrowser.org/b/PMWKUJZ
Chromium as chrome: http://whatsmybrowser.org/b/21ULSXJ
And you might want to be more specific on Dooble and Konqueror: http://whatsmybrowser.org/b/W3CJIKO http://whatsmybrowser.org/b/IHEV8VN
Konqueror has been at major version 4 for the past 7 years or so. Also, these operating systems are called "FreeBSD" and "Linux". "amd64" or "x86_64" is the arch they're running on here.
What's with that?
https://news.ycombinator.com/item?id=4499435
https://aboutmybrowser.com/
http://www.browser-details.com/
Ah, now there's your problem!
Seriously, no support person is ever going to need this information.
Or, alternately, have some stupid game change to other color depths (I'm looking at you UT), switch via Alt-Tab and kaboom.
The one we use, when we need to, is this: http://supportdetails.com/
All they have to do is put a recipient email address in the top, and hit "send details", and we receive an email letting us know what they're using.
You can even pre-populate the form:
http://supportdetails.com/?recipient=your@email.com
http://supportdetails.com/?sender_name=Jessica&sender=email@...
Making it a single click function.
Although I agree with other comments in this thread, that this is something your app should log, there are scenarios in which this type of tool is really useful. Namely: Registration/Sign-in errors, in which it's going to be extremely difficult to identify from log files which tuple relates to the user having issues.
But it's very useful.
And we use Streak, so when we get such an email it is automatically assigned to the bug and the CRM for that user... for free... using Streak filters.
I've never had a single person I've asked for the extra info from, fail to be able to send it.
It's not a blocker.
But... trying to get them to figure out "cut and paste and send email to help@foo.com" is a blocker. Then we're giving support for the support tools.