The B2G/Firefox OS user agent is of the form:

Mozilla/5.0 (Mobile; rv:18.0) Gecko/18.0 Firefox/18.0

Discussion / History

The Content HTTP Headers module owner has chosen (bug 777710) the following User Agent string for B2G (both embedded browser and app runtime):

Mozilla/5.0 (Mobile; rv:12.0) Gecko/12.0 Firefox/12.0

There were a number of strings under consideration for the B2G User Agent, but the key controversy was basically about whether to include "Android" as part of the OS identifier or not. So two strings can be taken as representative of the debate:

A ("Android"): Mozilla/5.0 (Android; Mobile; rv:12.0) Gecko/12.0 Firefox/12.0
B ("Bare"):    Mozilla/5.0 (Mobile; rv:12.0) Gecko/12.0 Firefox/12.0

Web Compatibility and Failure Modes

The key argument in favour of string A is that it causes more websites to send mobile, as opposed to desktop, content. John Jensen's metrics suggest that A causes an additional 9 percentage points of sites to send the same content as to the Android stock browser (96% vs 87% for B). Those metrics simply do a diff between the content sent to two UAs, so have some built-in inaccuracies. However, it is not denied that a UA which contains 'Android' leads to more mobile content. Even with our Reader mode and advances in intelligent zooming, desktop sites are harder to read and navigate on a mobile device than sites designed for mobile. Of course, many sites don't have a mobile version, so the user has to deal with this problem anyway. But minimising it is an important goal. If a site has a mobile version, B2G needs to get it.

However, A also opens us up to a different failure mode (which does not affect B), for which it has proved not possible to get metrics on the size of the problem. We don't always want exactly the same content as Android, because we aren't Android. This problem is most obvious and egregious when we get sent Android intents, which are instructions to installed Android apps to take a particular action (e.g. bug 777633 on YouTube) or "please install our app!" prompts or messages, where the app concerned is an Android app. As B2G is using "app" language about Open Web Apps, this could lead to great user confusion, as the user ends up on the Google Play Store and is very confused about why they can't install the app they have been recommended. This failure mode makes us look like a poor and less capable imitation of Android, and will lead to increased support costs for our partners as they deal with the confused users. In any market, but particularly the low-cost market which B2G is aiming to hit, reducing support costs is vital. Getting a desktop site rather than a mobile one is unlikely to lead to users calling their phone's support line.

Evangelism Story

Use of either string will require an evangelism effort. (If there was a magic UA string which made everything work, we would use it. The fact that there isn't one is why we are having this discussion.) But the story we have to tell for the two strings is very different.

If we use string A, the story we have to tell is: "You know you detect Android by searching for the word 'Android'? Well, in certain cases, where you are serving things that are really, really Android-only, then please add an exception. If <some way of detecting B2G>, then please treat it as not Android."

If we use string B, the story we have to tell is: "You know you have a mobile site? Please send it to all browsers which say 'Mobi'[0] in the user agent string, rather than just those which say 'Android' or 'iPhone'".

The mistake which leads to problems with string A ("I want Android? Then just look for 'Android'") is an easy mistake to make, and web developers are going to go on making it, at least until B2G has significant worldwide market share (2 years or more). Until that time, our evangelism team is going to have its hands full dealing with new sites which are making it, as more and more sites roll out mobile versions, associated apps and Android integration.

The mistake which leads to problems with string B ("Android and iPhone are the only mobile OSes") is likely to reduce as more OSes come online (e.g. Windows Phone), and as web developer best practice evolves to take account of the plural mobile web. We are pushing at a door which is already opening.

Story A is something only Mozilla will be telling sites. It's our evangelism team vs. the world. Story B is something Google, Nokia, Microsoft, RIM and Opera will also be pushing. If this is our story, we have allies. We can reach out to their evangelism teams to come up with a unified message, along the lines of geckoisgecko.org.

Success Metrics

Mozilla is increasingly a metrics-driven organization. Because the failures (desktop vs. mobile content) of string B are much easier to find programmatically than those of string A, using string B makes it much easier to create and drive metrics for our evangelism team. We can look at John Jensen's compatibility figures and drive the gap between us and the stock Android browser down by reaching out to the sites he identifies as sending us inappropriate content.

However, if we use string A, the team's task is to evangelise all sites which are recommending Android apps to B2G, or serving Android intents somewhere on the site. Their job then becomes much more difficult - they will need to manually inspect and use each site, or rely on user reports of brokenness. In-advance evangelism, which avoids users being exposed to problems, is much harder to do.

As the launch date approaches, it is also much easier to identify the hold-out top sites and deploy site-based user agent faking against them (bug 782453).

Using string A means that it is much harder to guarantee to our partners, via measured and documented progress, that we will be providing a consistent user experience at launch time. Using string B, where the necessary evangelism message is an easier one for developers, we have allies in promulgating it, and success metrics are available, is likely in my view to lead to better web compatibility at launch time, and therefore greater success for B2G.

Forward Compatibility

If we specify no OS, then in the future we can deploy B2G (or, more generally, WebRT, our app platform) on a wide variety of technology stacks without needing to re-evangelise sites who have mistakenly made OS-based UA sniffing assumptions. Sites can't take bad decisions based on information which isn't actually there. If WebRT has a consistent OS-less user agent everywhere, our evangelism job in the future will be much reduced. We are setting ourselves up for long-term success.

By contrast, if we want the same level of forward compatibility with string A, then the "Android" token will have to float around in increasingly less-appropriate places as time goes on.

Mozilla Mission and Market Placement

It is important to note that the factors in this section are not 'the deciding factors'. But it would also be wrong to deny that they are factors at all.

Mozilla's mission is to make the open web a better place. That mission is better served when we get mobile sites sent to any browser marked as "Mobile", which is what we have to do if we use string B. This makes the web better for all mobile browsers, increasing user choice. It is not better served if we try and persuade a large proportion of the world's mobile websites to have special code built in to handle our products alone, which we have to do if we use string A. Having to code for a specific browser or user agent, on either the client or the server side, is something Mozilla has historically campaigned against and worked to eliminate. We dissuade people from saying "Best Viewed with Firefox" in favour of "Best Viewed With Any Standards-Compliant Browser".

Mozilla's positioning for Firefox, for Open Web Apps, and for B2G is "the web is the platform" and, by implication, the underlying OS is irrelevant. Having no OS indicator in the UA string is in line with that market placement. Faking an OS which we aren't running on is an admission to some degree that our message actually isn't true.

Analogous Situations

It has been argued that B2G pretending to be Android is analogous with other sorts of user agent faking, which has worked for other people on other occasions.

For a long time, for example, the Chrome browser pretended to be Safari. However, these two situations are not comparable. A cross-platform browser with rendering engine A pretending to be another cross-platform browser also with rendering engine A is not at all the same thing as a browser on OS A pretending to be a browser on OS B. The failure modes for bad detection are very different, and much worse in the second case. Chrome, by using WebKit, could cope with pretty much anything that Safari could. No-one was sending Mac-specific content to a browser because it was Safari, because Safari also runs (ran?) on Windows. They would look for the OS indicator, which Chrome did not lie about. By contrast, see above for an explanation of the failure modes of Firefox OS pretending to be Android.

The closest analogy for Firefox OS pretending to be Android is of the iPhone and iPad pretending to be "like Mac OS X". However, in that case, both products (Mac OS X and iOS) came from a single company who had control of all of the variables. They could minimise any collateral damage by changing Safari, iOS, Mac OS X or any combination of the three. They also had first-mover advantage in the modern mobile web browser space. We are not in that position. I'm not aware of any other case where a browser has pretended to be running on a different OS to the one it is actually running on.

Summary

While using user agent B will lead to more desktop, as opposed to mobile, sites in the short term, all of the factors given above combine to mean that user agent B is the better choice for B2G, for Mozilla and for the web as a whole.

[0] 'Mobi' rather than 'Mobile' because Opera Mobile uses 'Mobi'.