This is a proposal for what the Firefox Mobile User Agent string should be, which has been endorsed by the Fennec team. It takes into account various newsgroup discussions, plus John Jensen's comparative analysis of various potential User Agent strings. (See below for more info on how to correctly interpret that data.) We hope to implement it before Fennec Beta on 31st January.
- 1 Summary
- 2 Rationale
- 3 Q&A
- 4 Open Questions
- 5 John Jensen's Data
Mozilla/5.0 (Android; Mobile; rv:12.0) Gecko/12.0 Firefox/12.0
Tablet (touch screen device):
Mozilla/5.0 (Android; Tablet; rv:12.0) Gecko/12.0 Firefox/12.0
Netbook (or tablet with attached pointing device, e.g. in a dock):
Mozilla/5.0 (Android; rv:12.0) Gecko/12.0 Firefox/12.0
(Examples are for Firefox 12; clearly, 12.0 would change for later versions. The three numbers would in all cases be the same, at least for the moment.)
User Agent strings accumulate cruft, and complex ones lead to server-side parsing which makes all sorts of wrong assumptions about browser capabilities which can't then be fixed on the client-side apart from by adding more cruft. Note what happened when sites started using "Gecko" as a synonym for "standards-compliant"; WebKit browsers still have "like Gecko" stuck in their User Agents. Here's a highly crufty example from current iPads:
Mozilla/5.0 (iPad; U; CPU iPhone OS 3_2 like Mac OS X; en-us) AppleWebKit/531.21.10 (KHTML, like Gecko) Version/4.0.4 Mobile/7B314 Safari/531.21.10
In addition, variance in the user agent string adds additional bits of entropy which can be used for browser fingerprinting. For this reason, we have done work in Firefox 4 and beyond to try and reduce UA string variance.
So our hope is to provide the shortest UA string possible, encourage good practice in sniffing, avoid giving developers footguns, and (as much as possible) avoid breaking existing working sites. It is not a goal to make sites which are currently broken to work - we don't think playing that game this way leads to a good outcome, and are committed to solving that problem through evangelism and compatibility improvements to our platform. But we want to and must nail down what the string should be, so we can start the work of evangelism without the risk of telling sites things which later turn out to become false.
The string above fits with the user agent for Firefox 4 and above on desktop. (Our proposal is intended to replace what that blog post says about Mobile.) It also fits with the guidelines of the Gecko User Agent String reference for Firefox products.
We have removed the "Fennec" identifier because we don't want sites to detect that instead of Firefox or "Mobile" or "Tablet". Our market share is currently small enough that we hope we can get away with this without breaking too many sites. Mobile Firefox is Firefox - it's not something else. That's one of its great selling points - you get the same browser engine everywhere. Our UA string should reflect that.
We have put the "Mobile" and "Tablet" identifiers among the platform identifiers because that's the logical place for them to go. Anyone sniffing for the string "Mobile" doesn't care where they are. Firefox is not going to match anyone sniffing for "Mobile Safari" wherever we put the word "Mobile" (and sometimes that string isn't present on WebKit anyway, as some Webkit UAs have "Mobile/<ver> Safari"). Mobile Internet Explorer uses "IEMobile". So really, just sniffing for "Mobile" is the way to find all these mobile browsers. (Although iPad also says "Mobile".)
On the tablet side, Opera already calls itself "Opera Tablet" when running on a tablet, so there is also precedent for using that string to identify tablets, and for varying a tablet UA compared to desktop. The iPad identifies itself as an "iPad" instead of a "Macintosh" (clearly, Apple isn't going to use the generic device name).
We have taken the opportunity to remove the Gecko date entirely (i.e. reduce to "Gecko/12.0" - as having something after the / is required by the HTTP spec). We have warned people we are going to do this, and starting on mobile means less up-front extra breakage (given that we are making other changes at the same time). Doing this in two batches might mean we'd have to re-evangelise sites. Changing this on desktop can happen on an independent schedule (after, or even before).
We need a "/" because some people detect "Gecko/" to distinguish from "like Gecko". And so we need something after the /. 12.0 had the most support; it means the version number is in 3 times, but we'll have to live with that.
What happens next?
This is a proposal which has been endorsed by the Fennec module owners as what they want to do for Fennec 11, the first release of Native Fennec.
Do you think this will fix everything?
No. There's a lot of hard evangelism work ahead. But hopefully if we are evangelising while using a UA string with the properties we outline above, it means we'll not have to do another lot of evangelism when B2G ships, or when/if Firefox ships on iOS, or some other development we can't even imagine happens. Part of what we are doing here is trying to make our job easier in the future.
Why "Mobile;" rather than "M;" or something shorter?
IE Mobile already has the string "Mobile" in their UA, as does Mobile Safari. Opera Mobile apparently avoids this string in favour of "Mobi"; however, that's an older product, and if there were problems with it today, we suspect the other two browsers would have seen it. Anyone who wants to include Opera as well can sniff for "Mobi" to catch them all. "Mobile" is also self-documenting.
Recent versions of Android use "Mobile" in the default browser's UA on devices that should be served mobile-optimized content.
Why have a tablet identifier at all? Why not just use the desktop user agent?
Often, given a choice of a "mobile site" vs. a "desktop site", the desktop site is better for a tablet. So we definitely don't want to call tablets "Mobile".
However, it is reasonable for sites to adapt behaviour to tablets as compared to desktops. For example, touch devices have no concept of "mouseover". There's no obvious way to indicate that other than in the UA. Some sites differentiate iPad vs. Mac using UA sniffing, and convincing them to use a mechanism other than UA sniffing would be difficult.
What about the hardware version?
There is a large array of hardware out there on which the platforms which support Firefox Mobile run, and doubtless there will be more in the future. A bug to add specific device information to the User Agent was WONTFIXED. The goal is for Firefox to work the same across all of these. In addition, adding hardware/OS information can have unexpected side effects; e.g. adding "Nokia" for the N900 led to us being served content appropriate for feature phones (non-smartphones).
Because our analysis shows it makes an enormous difference in terms of getting a decent mobile site - a difference of 0.14 on the difflib analysis, which is huge.
B2G isn't Android and may well not say "Android"; we will have to work hard to get sites to not sniff for Android going forward. But right now, the Fennec team judged that we need it in there.
This string has been ever-present in Firefox since the start, and in Chrome and Safari, and in IE since 7.0 (released October 2006) - IE 6 was "Mozilla/4.0", like Netscape Navigator 4.x. However, it's not present at all in Opera's default (non-spoofing) UA. Given this, is anyone still doing any detection at all with this string? If not, could we remove it.
Given that we are Mozilla, there's a strong emotional attachment there. But that may not be enough to outweigh the fewer-bytes-sent argument, if the compatibility impact is weak.
John Jensen's Data
John Jensen downloaded the top X mobile sites using various UAs to work out the effect of various changes; Brad Lassey proposed a matrix of possibilities and I added the one from this proposal and a few variants of it. His results are available as a Google spreadsheet.
When reviewing the spreadsheet, especially the first tab, remember that
- the numbers presented are averages, calculated over a thousand websites,
- that they measure difflib similarities, not "percentages"
- pay attention to the "coefficient of variation" or CoV, at the far right side of the first tab. This can loosely be described as a measure of how "spread out" the results are. In an ideal world, we would want to choose a UA that has a high mean score and a low CoV, indicating that most sites send mobile-enabled HTML to it and that those that don't, send HTML that is at least somewhat similar.