View source for Changing the UA String

Web browsers send a User Agent string on each request, which identifies the software being used and often some features of the platform. From time to time, proposals are made to change the User Agent string sent by Mozilla browsers. MDN [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent#firefox_ua_string records our current user agent string]. This page is an attempt to document the arguments for and against, to avoid needless repetition. (Although the arguments 'for' tend to vary from case to case more than the arguments 'against'.)

==Against==

===Promotes Bad Habits===

To some extent (the extent is a matter of debate), how detailed a User Agent string is affects how much User Agent sniffing websites do. User Agent sniffing is regarded as a bad thing for the web, and has bitten the Mozilla project multiple times. [http://badassjs.com/post/1217357060/hasjs Feature detection] is the recommended method of causing websites to vary based on UA characteristics.

===Fingerprinting===

The more variable parts there are in the User Agent string, the more bits there are with which to fingerprint the browser - which is a [http://panopticlick.eff.org/ privacy problem]. Mozilla has worked hard in the last 2 years to reduce the variability of the User Agent string to an absolute minimum.

===Once Added, Things Can't Be Removed===

Current User Agent strings contain a pile of cruft which is required for backwards-compatibility. The longer a piece is in there, the more frozen it becomes. The first release of Mozilla updated the Mozilla/ token from Mozilla/4.0 to Mozilla/5.0, but it's never been incremented since. There was a desire to remove the Gecko date because it increased the browser's fingerprint, but it could not be removed because too much broke - it had to be fixed to a particular date.

This means that the barrier to adding new parts should be high.

===Users With UA Strings the Author Didn't Test With, Get Worse Content===

Every difference in the UA string between two Firefox instances is an opportunity for sites to intentionally or accidentally send different content to two Firefox instances. This means that two users with equally capable systems can get different content and one of the users gets a substantially worse experience. Typically, the worse experience is with a configuration that the Web author didn't test but had prejudices about (or just plain bug combined with lack of testing).

Also, this phenomenon makes it harder to debug problems related to sites, because the person reporting the problem and the person debugging the problem can get different content.

===Each Addition Bloats Every Request===

The User Agent string is sent on every request. Therefore, like any such header (e.g. also the Accept: header), size is very important. The total bandwidth used by HTTP requests across the internet every day is mind-boggling. Also, if the size of your initial request gets too large, it ends up being broken into two packets, with corresponding possible performance penalties.

===Gecko Can Never Lead===

If Firefox adopts another browser's User Agent, it will always be assumed that we have the capabilities of that other browser - even if we have better capabilities. So it is very hard for us to drive the web forward in leadership.

==For==

===Feature Detection Only Goes So Far===

A site needs to know some browser capabilities when rendering the very first response and so, if they are to avoid an extra round-trip and page load, they need to be provided with the necessary information up front.

===The Web Is Just Broken===

If a class of sites have content suitable for Firefox but are not sending it to us due to UA issues, changing the UA fixes the problem - whether or not you think they should have done that in the first place, that's what they've done and we have to deal with it.

===Can Be A Quick Fix For A Large Gain===

Changing the user agent string is not difficult, and some changes (when there is data to support them) can lead to significant improvements in user experience in a short space of time. When time to market is important, this speed compared with evangelism-based approaches can be important.

==Notes==

* One alternative to UA string changes is evangelism. Particularly if only a few widely-used libraries need to be changed, it may be possible to bend the web to our will. Mozilla has done this before around the time of the Netscape 6 and Mozilla 1.0 releases with a massive evangelism effort. We can do that again if we have a task to rally around.

* Another alternative (that some competing browsers use) is to send a modified UA to specific popular sites in order to ensure that they receive the most appropriate content, regardless of broken UA assumptions on those sites. Whilst hard-coding specific sites is suboptimal, it may still be preferable to giving all other sites a more detailed UA, which will only encourage further problems later on. This need only be a temporary measure until the evangelism efforts above pay off - and could be implemented via about:config, or else a "ship-by-default on platform/form-factor X" addon that can easily be disabled by the user.

* For the best chance of success, proposals for change should to be accompanied by documented evidence of the improvements they bring.