And now we have Chromium-based Opera which can't call itself Opera and has to use "OPR/16" instead, and pretends to be Chrome, which pretends to be Safari, which pretends to be KHTML, which pretends to be Gecko, which pretends to be Netscape.
The real question is, is this still needed in the modern web? I have never used the user agent to serve different content. I do expect that some sites still use the user agent for detection of mobile browsers but that is also deprecated for people with common sense..
For instance, I wrote an IndexedDB-heavy web app. It doesn't work in browsers that don't support IndexedDB. So I do feature detection and if IndexedDB is not supported, I show an error message telling the user that if they want to run the app, they have to use a more modern browser like Firefox, Chrome or IE10.
...except on iDevices, where it is literally impossible to install any browser that supports IndexedDB, despite the fact that it is possible to install something called "Google Chrome" that is not really Google Chrome. So I do user agent detection to display a different message to those users, so as to not give them false hope and confusion.
Admittedly I could invest more time to try to get it working, but iOS represents a relatively small fraction of my users and even a working shim could have problems (IIRC there are serious bugs with WebSQL in iOS 7, not sure if they've been fixed; also, I don't know what this shim approach would do to performance in an IndexedDB-heavy app).
The User-Agent field is a great way to detect a polite robot (and even, if it supports robots.txt, to ask it to avoid certain pages). So this header field is a useful signal for analytics.
It's not at all trustworthy, but in practice it's useful.
The user agent (UA) string is used by almost every major web brand for one or more of the following purposes:
- To serve different levels of experience to different classes of browsers. This is necessary if you want global coverage i.e. all classes of devices and connectivity. The payload of desktop version of Google is fully 140x bigger than the lightest mobile version, Facebook is similar (check this on http://prism.mobiforge.com). RWD can't do this (many RWD sites simply don't load at all on lower-end phones).
- Serving different experiences to different types of devices e.g. desktop / mobile / TV etc. Don't think this is necessary? Try some of the sites mentioned with a different UA strong and see how it feels.
- Analytics. Google Analytics, Omniture etc. all rely on the UA string to identify types of devices/browser.
- To offer links to the correct app stores for the various mobile OSes
- To make sites faster/lighter for lower end devices. This is important for low-speed connections, faster page loads, metered data plans.
Ah good point.
But what I really meant, and that isn't really clear from my post: Is wether we still need the addition crap that is in a user agent string.
A user agent should be more like this: <Operating System> <version>, <browser> <version>, <devicetype>, <connection type>(high speed unmetered, 3g metered etc)
jQuery does not actually solve every possible cross-browser compatibility issue. I still occasionally have to code around some browser issue, especially considering the lack of good plugins to support localStorage.
A great explanation that also made me laugh. I've never really thought of the browser vendors trying to impersonate each other before; sort of, "competing" for content. I always thought they just did what they liked and we all had to hack around it.
Why do you capitalize Java like that? It's not an acronym or an abbreviation. It's just a word - named after the type of coffee from the Indonesian island of the same name.
Actually this history has one minor mistake (there may be more); Microsoft didn't make their own web browser, well at least not initially, they licensed their code from Spyglass.
> And Internet Explorer supported frames, and yet was not Mozilla, and so was not given frames.
I don't think that is correct. IE 2 didn't support frames. IE 3 did, but 2 didn't. I remember waiting for IE3 to get more market share so that I could safely use frames.
I can't tell you what feature made them fake the user agent, but it wasn't frame support.
Sounds like we could really use a "User-Agent-Features" header or something similar. Or we just say screw it and make a new standard for the User-Agent header, then users can run in compatibility mode when needed.
The author reaches a trite conclusion uninformed by facts. The user agent string is used by at least 90+% of the Alexa 100 to improve user experience.
There is a silent evidence problem here. Successful use of the user agent string improves the user experience but goes unnoticed; failures are very apparent.
From the article:
"user agent string was a complete mess, and near useless"
I haven't had to deal with user agents in a while, thankfully. Except today; the client wants the user to be presented the mobile site we built, or the old desktop site, depending on user agent. I'm not going to parse no user agent strings though - there's an open source library / database called WURFL [1] that can do all those things. Hopefully.
The pseudo-Biblical writing style reminds me of The Book of Mozilla[1], perhaps the coolest browser easter egg in existence, which, sadly, Chrome decided not to implement.
Wow this is awesome, it answers so many questions.
I'm actually surprised that Mozilla didn't sue the other browser for using its name in their User-agent browser. This may have secured Mozilla's place as #1.
On a related note W3C+Mozilla are trying to document use-cases for UA sniffing: https://etherpad.mozilla.org/uadetection-usecases