Edit 9/9/2010: This information has been superseded by an updated post here. Please refer there for final information on the changes for Firefox 4.
With a title like that, you just know this is going to be fun. (No, seriously.)
The user agent string is one of those wonderfully eclectic things, a balance of modernity and antiquity. Except mostly skewed toward antiquity. It’s grown, piece by piece, over the years; because everyone has their own special way of parsing it, it’s a notoriously sensitive beast. Adding to it is relatively simple, but removing or rearranging bits is not.
If you’re a web developer and you rely on bits in the UA string, this post is definitely for you. As it so happens, the UA string for Internet Explorer 9 has undergone some revision, and Microsoft has recently announced the string for IE Mobile. This makes the time ripe for a revision so that web developers can make the necessary changes to sniffer code all at once.
Here are the changes we’ve made so far for Firefox 4, on the Big Three platforms (for a complete reference, see https://developer.mozilla.org/En/Firefox_User_Agent_String_Reference):
Mozilla/5.0 (Windows NT 6.1; rv:2.0.1) Gecko/yyyymmdd Firefox/4.0.1
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0.1) Gecko/yyyymmdd Firefox/4.0.1
Mozilla/5.0 (X11; Linux i686; rv:2.0.1) Gecko/yyyymmdd Firefox/4.0.1
What’s changed, you say? Here’s what:
1) The "Windows; " prefix is gone from the (surprise!) Windows-specific string.
2) The locale (e.g. "en-US; ") is gone. The locale of the browser is not always the same as the locale the user prefers to view content in — the HTTP Accept header is the recommended source of this information.
3) The "U; " is gone. Back in the day, this was used to denote browsers with strong encryption from those without. Nowadays, no browser ships with weak encryption. This means that if you’re sniffing for "U; ", you should stop doing so, or sniff for the lack of weak encryption ("I; " or "N; ").
4) Testing builds of Firefox (Minefield nightlies and prerelease builds) will now identify themselves as "Firefox/x.y.z", just like release builds.
We may also remove the "Macintosh; " from the Mac UA string, and the way a Linux x86 32-bit browser build running on an x86_64 processor is identified; if we do, you’ll hear about it here.
It’s also worth noting why we didn’t change some things. The "X11" part of the Linux string may appear redundant, but it’s actually not: desktop machines are almost exclusively running X11, but Android phones are not. For reasons like this, the various platform-specific parts of the string are important to know. For instance, there are different tokens for Windows 64 on x64 or IA64, or WoW64 (a 32-bit browser on a 64-bit Windows); PPC or Intel on Mac OS X; and the various environments and architectures for Linux. A list of the common variations can be found at the link above. There’s also a text file here for your testing convenience.
There are some other important changes relating to how the UA string can be modified by external programs, Firefox addons, and users themselves. I’ll detail these changes in an upcoming post, but suffice to say: the days of horrendously long and arcane strings are over.
Now, if you’re a web developer, take note! These changes will be in Firefox 4 Beta 5 (soon to be released), so if you want to be ahead of the game, you’re welcome to test against it. As noted above, for a complete list of UA strings to test against in all their glorious variations, see the link above or the text file. Happy sniffing!
Don’t test against Firefox in the UA string, test against Gecko http://geckoisgecko.org/
Comment by mcsmurf — August 24, 2010 @ 2:42 pm
Still way too much data and differentiation. The Gecko build date and the last point version number should go; as:
Mozilla/5.0 (Windows NT 6.1; rv:2.0) Gecko Firefox/4.0
Look at IE9. Less different strings = better caching. Why would a web server need to know about the date/patchlevel?
Comment by fsdg — August 24, 2010 @ 2:58 pm
Love it! I love making things simpler and removing old cruft. Any reason we’re keeping around the X11 in the Linux version? Couldn’t it be simplified like the Windows string?
Comment by Scott Baker — August 24, 2010 @ 2:58 pm
It’s a damn shame we couldn’t get rid of the Mozilla/5.0. And the Firefox/x.y.z.
Comment by Zack — August 24, 2010 @ 3:00 pm
It would be great if there was a W3C spec that defined how a UA string should be set out. Even still, it’s good that it’s been shortened.
Comment by Josh — August 24, 2010 @ 3:19 pm
If you’re a web developer forget U-A strings, and do your features detection in saner ways, please!
Comment by Gustavo Noronha — August 24, 2010 @ 4:16 pm
[...] about earlier, nor in today’s code. And that is good so, because both Internet Explorer and Mozilla Firefox will no longer add the browser language or locale to their User Agent Strings in the future. Other [...]
Pingback by How to do user language/locale detection quickly without Zend Framework | mpopp.net blog – Markus Popp — August 24, 2010 @ 4:39 pm
Daniel: On the MDC page you link to, I see that Fx4 for Mac OS X will say “Intel” even when run on a PPC. I suppose it is a typo?
fsdg: I beg to differ. If the Gecko build date goes away and in addition to it the last point version of both Firefox and Gecko, how can we find precise regression windows for nightly builds? Remember that the UA string is pasted automatically at the top of the description in every bug report (when using the guided form). If we can only say that a particular bug “happened at some point in the life of Fx 4.0″, there’ll be no way anyone can find which Mercurial changeset caused the bug.
Comment by Tony Mechelynck — August 24, 2010 @ 5:58 pm
[...] the original post: User Agent string changes coming in Firefox 4 « Daniel Witte var a2a_config = a2a_config || {}; a2a_config.linkname="User Agent string changes coming [...]
Pingback by User Agent string changes coming in Firefox 4 « Daniel Witte | Firefox News on Twitter — August 24, 2010 @ 6:25 pm
@Tony script can still have access to that information, it just doesn’t need to be blasted out in every. single. request.
Comment by fowl — August 24, 2010 @ 7:35 pm
I’d like Mac string to show 64-bitness of the machine, so I could offer better version of my software to download (32-bit macs are 5% minority, and double code size).
Comment by kl — August 25, 2010 @ 3:09 am
[...] Read more: User Agent string changes coming in Firefox 4 « Daniel Witte [...]
Pingback by User Agent string changes coming in Firefox 4 « Daniel Witte | Firefox Blog — August 25, 2010 @ 5:41 am
Another thing worth noting is that this information (like the is currently still available via the JavaScript navigator object. So if you do need to find it out, and maybe do it in JavaScript anyway, then you can just as well use that object.
I second the call to drop Mozilla/5.0 though. Considering *every* browser on the planet now uses that, it’s become semantically completely useless and a waste of bandwidth.
Comment by Fred — August 25, 2010 @ 6:04 am
@Josh: The HTTP/1.1 spec gives information about the UI string.
@fsdg: Invalid as per HTTP/1.1.
@Scott: Android. Maybe DirectFB support?
@Zack: That is really against the HTTP/1.1 spec.
@Gustavo: Thank you.
Comment by Keith — August 25, 2010 @ 7:59 am
Keith: I don’t believe that the spec says that what fsdg posted is invalid per the definitions.
Comment by Dan — August 25, 2010 @ 2:46 pm
[...] id will show up. This build id will be different for each platform. Mozilla developer Daniel Witte covers the changes in depth on his blog. There’s also a more complete reference on the Moz Dev Center [...]
Pingback by Get to Know Your New User Agent Strings | Tech Alps — August 25, 2010 @ 5:02 pm
fowl: if script has access to it, there’s no fingerprinting gain; and if it goes away from Help=>About, there’s a debugging loss (especially when debugging Thunderbird, which cannot report to Bugzilla, or when saying in a later comment “Please don’t close it WFM, I’m still seeing this in “)
Comment by Tony Mechelynck — August 25, 2010 @ 5:07 pm
I also agree with the call to drop Mozilla/5.0. This is absolutely useless if it doesn’t mean anything and doesn’t break anything.
Comment by Omega X — August 25, 2010 @ 5:08 pm
oops… “I’m still seeing this in (insert buildID here)” — I forgot that almost anything between less-than and greter-than will be removed.
Comment by Tony Mechelynck — August 25, 2010 @ 5:10 pm
[...] id will show up. This build id will be different for each platform. Mozilla developer Daniel Witte covers the changes in depth on his blog. There’s also a more complete reference on the Moz Dev Center [...]
Pingback by Media Blog » Blog Archive » Get to Know Your New User Agent Strings — August 25, 2010 @ 5:46 pm
Thank you Mozilla for doing something about this ridiculous piece of cruft. Now if only Webkit would shorten their 50-mile-long UA string too…
Comment by ant — August 26, 2010 @ 10:09 am
[...] id will show up. This build id will be different for each platform. Mozilla developer Daniel Witte covers the changes in depth on his blog. There’s also a more complete reference on the Moz Dev Center [...]
Pingback by Get to Know Your New User Agent Strings | Programming Blog — August 26, 2010 @ 5:15 pm
[...] Mozilla announced User Agent document.write(unescape('%73%74%72%69%6e%67')); document.write(unescape('%63%68%61%6e%… [...]
Pingback by Tech Thursday: Vote Pacman, periodic HTML5, robot laws, and realtime web | The Online Blog — August 28, 2010 @ 1:42 am
Given that my UA string is one of the two most personally-unique things Panopticlick can detect when NoScript is doing its job (HTTP_ACCEPT being the other), I’d think that the less data we can get away with leaking, the better.
https://panopticlick.eff.org/
Comment by Stephan Sokolow — August 29, 2010 @ 7:39 am
[...] As of Beta 5, Firefox has a new User Agent String. [...]
Pingback by Add-ons Review Update – Week of 2010/09/14 « Mozilla Add-ons Blog — September 14, 2010 @ 5:26 pm