Firefox OS User Agent Partner Changes Policy

Note: The Firefox OS user agent, along with the rationale behind its selection, is documented on the Mozilla wiki.

Mozilla partner organizations that make use of Mozilla branding must not modify the Mozilla-specified Firefox OS User-Agent string ("UA") or add/modify headers that have a similar effect (e.g. Device-Stock-UA, UAProf, X-Original-User-Agent, X-Device-User-Agent or X-OperaMini-Phone-UA).

The rationale for this requirement can be divided into pragmatic and principled reasons.

Pragmatic reasons:

Risk of individual site regressions 

Changing the UA may result in a site sending desktop instead of mobile content to Firefox OS

Risk of framework regressions 

Changing the UA may result in updates being required for commonly used Web UA detection and media frameworks

Future compatibility issues 

Changing the UA may cause compatibility problems for future Firefox OS devices

Principled reasons:

User privacy 

Adding certain tokens to the UA reduces user privacy by increasing "fingerprintability"

Effect on the Web 

Relying on specific tokens for UA detection is a barrier to entry for new Web clients

For sites that cannot adapt in the short term, Firefox OS includes a short term work-around that can be enabled on a per-site basis.

Pragmatic reasons for not modifying the Firefox OS UA

Mozilla suggests that it is not in the best interest of any partner to modify the Firefox OS UA for the devices that they ship, for the following reasons:

Risk of individual site regressions

Mozilla has been informing sites about the chosen default Firefox OS UA since the decision was made in July 2012. Mozilla and our partners have worked with a large number of sites, such as Google, Facebook, and Twitter, to ensure that the correct content (i.e. mobile content) is delivered to Firefox OS. Due to the widespread use of UA detection, a change to the UA risks sites no longer detecting Firefox OS as a mobile device and reverting to sending desktop or feature phone content to Firefox OS, leading to a worse user experience.

Mozilla has also worked with media companies, such as YouTube, Vimeo, and SoundCloud, to ensure that content that is frequently embedded within sites is functional on Firefox OS.

Risk of framework regressions

Mozilla has worked with UA detection frameworks, such as WURFL, Categorizr, and 51Degrees, and they all now recognize Firefox OS. Changing the Firefox OS UA would require going back to all of these companies to make further changes. Assuming all of the companies do make the requisite changes, there can be significant lag time in the adoption of these changes by sites that make use of these frameworks. In the mean time, users may get inappropriate content.

Future compatibility issues

Mozilla wants to encourage the use of detection methods which will work on all Firefox OS devices, both ones that currently exist and ones which have not yet been invented. Specifying a different UA string for each Firefox OS device provides a site with a mechanism to, accidentally or deliberately, design their code to work with only a subset of Firefox OS devices. This is a bad for the Firefox OS ecosystem and for the open Web.

Principled

The above pragmatic objections apply to most types of proposed changes. By contrast, the particular principled objections which apply depend on what change is being requested. But the following can be said:

User Privacy

Mozilla strives to provide greater privacy for users. Therefore, we have been working to reduce the level of "fingerprintability" of different browser configurations - that is to say, how uniquely identifiable a particular user's browser is to sites through detection methods of which the user is unaware. (i.e. server-side methods) Adding e.g. hardware information to the UA reduces privacy by increasing fingerprintability.

Effect on the Web

A request to add hardware information to the UA supports the use case of a site tailoring its content to the hardware in use. However, the Web platform already provides an alternative method for feature detection through the use of on-device feature testing in JavaScript, which does not rely on large, fragile and slow-to-update databases mapping hardware identifiers to capabilities. This method is more reliable than the database-backed way and is also future-proof.

The database-backed method also puts up market barriers to entry for new Web client/browser/platform participants, whose user agent strings and device characteristics will not be in the database.

Another request is that we add an operating system indicator. We do not specifically identify devices as running Firefox OS in the UA because "the Web is the platform". In this broader context, the underlying OS is irrelevant. Having no OS indicator in the UA is in line with this dictum.

Mozilla's mission is to make the open Web a better place. That mission is better served when mobile sites are served to any mobile browser. Ubiquitous access to mobile content increases user choice in terms of practically viable mobile clients. It is contrary to Mozilla's mission to enable mobile content for Mozilla's products alone. Having to code for a specific browser or UA, 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".

Short term work-around

It is impractical to think that the mobile Web can be "fixed" in the short term. In support of the Firefox OS user experience, Firefox OS has the capability to send a custom UA to a specific site in order to force mobile content. Often the change is simply to include the "Android" token in the UA, thus masquerading Firefox OS as Firefox for Android. The process for adding a site to the UA override list is documented on the Mozilla wiki. Mozilla has already added certain sites to the list which are important in Firefox OS launch markets. Mozilla permits partners to add a reasonable number of other individual sites to the list after confirming that doing so will result in an improved user experience. We strongly recommend that partners not to rely on the UA override list as a long term solution and encourage them to open a dialogue about moving to a more future-proof model of capability detection with each site on the list.

Alternatives

One use of putting e.g. a device identifier in the UA is to look up information about the device (e.g. screen size) in a server-side database. However, this method fails when a device is not in the database, or not in the version the site is using. Mozilla recommends that the best way to find this information is simply to ask the device at the time the user visits the site or uses the app. Properties like screen size are available through JavaScript.