Firefox user-agent string is too unique

[Daniël van Eeden]

As shown on http://panopticlick.eff.org

The useragent string "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2" is too unique and in combination with a fairly unique plugin list this allows browser fingerprint tracking, which is bad for privacy.

I would suggest this change:
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0) Gecko/20100101 Firefox/10.0

This removes makes the version number less unique. Also the Gecko version could be made a bit more generic.

[Henri Sivonen (hsivonen)]

Steps to reproduce:
 1) Load http://www.delorie.com:81/some/url.txt

Actual results:
The User-Agent header exposes the security patch level as either a minor version number or as an alpha/beta/pre indicator. This data is exposed twice: in the Gecko version and in the application version.

While it is of value to expose this data to e.g. AMO, exposing it to all sites makes the browser more fingerprintable (see https://panopticlick.eff.org/ ) and doesn't serve a purpose more important than user privacy. Point releases don't change functionality beyond security and stability fixes, so sites shouldn't be sniffing the patch level anyway.

Making trunk, alpha and beta builds look like release builds for sniffing purposes reduces sniffing-related failures that waste time when treated as functionality-related regressions by mistake.

Expected results:
Expected the version numbers to show the major version of the most recent Firefox beta that Mozilla has shipped and not to show the security patch level or an alpha/beta/pre indicator.

Additional information:
Internet Explorer doesn't expose the security patch level in its UA string.

[Henri Sivonen (hsivonen)]

To make detailed config available to AMO, etc., there should probably be a JS API that's callable only from https-verified *.mozilla.com and *.mozilla.org origins (overridable for downstream distributors).

[Mikeperry-unused (mikeperry-unused)]

It's also worth noting that this change may be helpful to frustrate drive-by-download attacks that provide exploits depending upon the useragent and platform string.

However, for it to really mean anything, Bug 429070 would also need to be fixed, because it is possible to accurately determine patchlevel and OS by inspecting Components.interfaces and Components.classes from content-window script.

[Trev-moz (trev-moz)]

Bug 429070 isn't the only relevant information leak. There is also navigator.productSub as well as the resource:// protocol that can be used in script tags (e.g. distinguishing Firefox 3.6.4 and 3.6.6 can be easily done by loading resource:///greprefs/all.js as a script).

[Trev-moz (trev-moz)]

(In reply to comment #2)
> inspecting Components.interfaces and Components.classes from content-window
> script.

Components.classes is restricted area, only accessible with UniversalXPConnect privileges. Bug 429070 is only about Components.interfaces.

[Davemgarrett (davemgarrett)]

This bug is covering multiple interconnected suggestions. There are basically 3 different changes already suggested here:

1) Drop minor versioning
2) Drop Gecko build date
3) Use stable Firefox branding and versioning in development builds

As to each point:

#1:
I like the idea but I think it won't affect as much as it looks. Most people should ideally be on the latest minor update to their major version. Anything less than 100% update rate is a problem with our updating system, which includes users simply not doing it. This needs to be fixed, and simply exposing the progress is a side effect. As to detecting exploits, that can be done by simply trying them all and seeing what sticks. I don't think knowing what to shoot for is that big of a deal as things go. There's also other plenty of way worse things that need fixing before this will make any real difference (as noted).

Doing #1 would also break Mozilla Addons and would need some replacement detection method, as noted in comment 1. I don't think doing all of this is worth the effort. I can't argue that this wouldn't help fingerprintablity, but I am arguing that it's not necessarily the best way to go at this point.

#2 for stable builds:
No effect. The Gecko version, build date, and application version are all directly correlated. The build date is duplicate information that isn't needed, but it adds nothing to a fingerprint as-is.

#2 for branch/trunk builds:
Really helpful. With branch/trunk builds this date is really fingerprintable and getting rid of it would be great. Alpha/beta users get no real effect, as with stable.

#3:
Would help with some (but not all) non-stable UA sniffing problems, but not much else aside from the same effects of #1. I don't see too much of an improvement from betas claiming to be stable, and I imagine you might be able to find a way to get something to break. (i.e. site "supporting" a version as soon as an alpha is released, then breaking when stable comes out with no way to tell them apart) If you really wanted to you could probably figure out what things really are by feature detection for API changes in some instances. It's also a smaller population of users which means more fingerprintable though less widespread of an effect.

[Davemgarrett (davemgarrett)]

#2 in comment 5 was also filed separately as bug 572661

[Dale-bugzilla (dale-bugzilla)]

The problem with comparing this to IE, is that IE you can at least look at all the patches applied on your own system. I believe Mozilla is even better the way it is. We're most likely to go backwards with support if we change any of these.

[Henri Sivonen (hsivonen)]

(In reply to comment #7)
> The problem with comparing this to IE, is that IE you can at least look at all
> the patches applied on your own system.

I am not suggesting removing the detailed version from the about box.

[Davemgarrett (davemgarrett)]

One other downside to removing minor versioning from the UA: we wouldn't be able to easily tell if a user posting a bug report or support request has fully updated their browser anymore.

I personally think that this move would be far more of a headache than it's worth and WONTFIXing is probably the best route in favor of just bug 572661.

[Henri Sivonen (hsivonen)]

(In reply to comment #9)
> One other downside to removing minor versioning from the UA: we wouldn't be
> able to easily tell if a user posting a bug report or support request has fully
> updated their browser anymore.

One option would be making an async JS API for querying detailed information, and that API would require user authorization per-site like geolocation. I think it's the wrong tradeoff to expose the data that satisfies use cases on a handful of Mozilla's own sites to the whole Web with every HTTP request.

[Davemgarrett (davemgarrett)]

Per-site authorization should be restricted to things that are actually important privacy issues. Telling a site your exact physical location is a privacy issue, but simply knowing the specific Firefox minor version isn't really as important. (again, it might be able to determine it progmatically) I don't want to create another bug the user prompt which would possibly just have a user clicking yes anyway without thinking.

The compromise solution would be to remove the minor version from the UA but expose it via JS with no extra authorization required. This would prevent its usage for server-side only fingerprinting but still allow sites to get at it. Client-side fingerprinting wouldn't be affected that much, as already stated it could figure out the minor version via other methods if it felt like it. However, even this solution feels like overkill to me. (and it would still break the current simple method to get full version info for support here and elsewhere, which is not an insignificant problem)

[Davemgarrett (davemgarrett)]

To extend the idea in comment 11, the HTTP request could send only a skeleton UA such as simply "Gecko/2.0 Firefox/4.0" without anything very fingerprintable like minor versions or OS/platform. (locale already removed in bug 572656) The full UA would still be available via navigator.userAgent in JS for sites to use as needed on the client-side. This would essentially slash the ability to do pure server-side fingerprinting but not cause unworkable problems elsewhere. (Accept-Language still allows some, but not nearly as much as the rest)

[Davemgarrett (davemgarrett)]

But of course comment 12 would break any server's ability to send a different lightweight version of a page to mobile OSes, not to mention useful stats.

[Rsx11m-pub (rsx11m-pub)]

Sorry, I can't follow the motivation for either this bug or bug 572661 (and whatever other companion bugs which may have been filed on the UA string).
For an administrator, this information is usually quite useful in enterprise settings (e.g., to identify users who don't update their laptops on a regular basis). Homogenizing the UA string would remove that capability. The similar importance for user forums has already been stated in bug 572661, and if you ever worked in such a forum or help desk, you know what a hassle it is to get version and platform information reliably from the reporter.

If a user is concerned of fingerprinting, there is general.useragent.override to make up whatever you want. If someone knows how to compile his or her own version, they certainly are aware of that possibility. Spotting 3rd-party downloads may again be useful from an administrative point of view.

> (comment #12) locale already removed in bug 572656 ...

Not true, intl.accept_languages is still exposing this to the web server. :-\
Geolocation or even IP resolving is doing a better job to localize a client anyway, so omitting the locale substring won't help much here.

[Mnyromyr (mnyromyr)]

Note also that Thunderbird sported a minimal UA for some time and ruefully restored it. I see no point in hiding helpful information when you're even more recognizable by fingerprinting fonts and addons. And security by obscurity is a myth.

[Henri Sivonen (hsivonen)]

(In reply to comment #14)
> For an administrator, this information is usually quite useful in enterprise
> settings (e.g., to identify users who don't update their laptops on a regular
> basis).

How do admins deal with IE updates in an otherwise similar scenario?

In any case, if the use case is about tracking stuff within your own enterprise, on the face of things, it seems like a wrong solution to address the use case by sending data all over the Web.

(In reply to comment #13)
> But of course comment 12 would break any server's ability to send a different
> lightweight version of a page to mobile OSes,

With my user hat on, I'd consider it a desirable feature for sites not to be able to sniff mobility from the UA string. When using a mobile device, it's incredibly annoying if you don't find the content you are looking for at the same address where you'd find it when browsing from desktop or to get content that has been dumbed down assuming that all mobile browsers have limited and broken capabilities. When browsing on desktop, it's very annoying to get accidentally sniffed as mobile.

> not to mention useful stats.

I think statistical curiosity should have the least weigh when making the decision of what to expose.

[Rsx11m-pub (rsx11m-pub)]

(In reply to comment #16)
> How do admins deal with IE updates in an otherwise similar scenario?

Ha, mentioning the MSIE UA string in this context was the worst example you could choose, it's full of additional junk these days indicating where the download came from and what features are installed. Most notably, the .NET versions are broadcasted (and thanks to Microsoft's carefulness also with Firefox browsers unless the user disables the global add-on and removes the UA-string additions it made), so this is a nice way for fingerprinting.

In contrast, look at Chrome or Safari, which are presenting the current version information in the UA string (so does Apple Mail, since Karsten mentioned Thunderbird). Nobody seems to have concerns there?

[Rsx11m-pub (rsx11m-pub)]

For the sake of completeness, here an arbitrarily fetched MSIE8 UA string: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET
CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.2; Tablet PC 2.0; MS-RTC LM 8)

Tells you a lot, does it?

[Davemgarrett (davemgarrett)]

(In reply to comment #14)
> If a user is concerned of fingerprinting, there is general.useragent.override
> to make up whatever you want.

*This is not true.* Doing an override yourself makes you significantly MORE fingerprintable, not less. This is because most people don't do this, thus any non-standard anything is highly fingerprint worthy. The only way to make a dent in the problem is to do it for everyone at once.

> > (comment #12) locale already removed in bug 572656 ...
>
> Not true, intl.accept_languages is still exposing this to the web server. :-\

I wasn't specific enough I guess. In comment 12 there I was specifically talking about the UA. The locale token was removed from the UA. Note that this was the UI locale, not the accept language locale (also noted in comment 12 to still be in requests). These two may coincide or they may not, depending on user setting.

> Geolocation or even IP resolving is doing a better job to localize a client

Location is a horrible way to guess locale, as discussed elsewhere. Doing so gives many people the wrong locale because they don't speak the local language.

(In reply to comment #15)
> you're even more recognizable by fingerprinting fonts and addons.

Plugins are a big problem not addressed here, but elsewhere. Extensions are a UA problem also mentioned. Fonts, by the way, you would largely be immune to sniffing of (at least via panopticlick.eff.org) if you used Flashblock or another click-to-play Flash system of some kind. (Mozilla may or may not build one in at this rate)

> And security by obscurity is a myth.

Very true. I noted above that hiding minor versions won't really help with security, but that's as far as that axiom goes here. Remember, this bug is about fingerprintablility, not security, and obscurity is the actual effective goal here.

(In reply to comment #16)
> > not to mention useful stats.
>
> I think statistical curiosity should have the least weigh when making the
> decision of what to expose.

Lower weight, yes, but not something to ignore.

[Rsx11m-pub (rsx11m-pub)]

> (In reply to comment #19) This is because most people don't do this, thus any
> non-standard anything is highly fingerprint worthy. The only way to make a dent
> in the problem is to do it for everyone at once.

Even if you don't change it *and* remove the date *and* remove the version,
many 3rd-party builds will still use the general.useragent.extra machanism to
add their own sub-version information, so those could still be spotted and fingerprinted. Sorry, but I fail to see the point of these efforts here...

[Henri Sivonen (hsivonen)]

(In reply to comment #17)
> Ha, mentioning the MSIE UA string in this context was the worst example you
> could choose, it's full of additional junk these days indicating where the
> download came from and what features are installed. Most notably, the .NET
> versions are broadcasted (and thanks to Microsoft's carefulness also with
> Firefox browsers unless the user disables the global add-on and removes the
> UA-string additions it made), so this is a nice way for fingerprinting.

Microsoft is getting rid of that stuff in IE9.

[Davemgarrett (davemgarrett)]

(In reply to comment #21)
> Microsoft is getting rid of that stuff in IE9.

We may too -> bug 581008

[Davemgarrett (davemgarrett)]

rsx11m: "[non-parity-WebKit]" isn't really a useful whiteboard tag, by the way. There's a lot of things that aren't parity with things; we don't list them all.

[Rsx11m-pub (rsx11m-pub)]

I had only added it due to the [parity-IE] tag which was already present. ;-)

[Dale-bugzilla (dale-bugzilla)]

In the interest of this bug not getting completely side tracked from the build date issue:

Locale/Security are other bugs as noted already.

The Mobile deviceType was just removed last night from the UA, and was wontfix either (bug 524339), but the code is gone now (bug 580341), so sites cannot sniff for Nokia, N900, or Sprint or what have you. The Android Mobile devices sends the device id in the UA and the carrier, so in that case you can easily fingerprint, consider Firefox doesn't have it, I guess that is a plus.

In the case of Mozillazine, the UA strings for all the other posts are revealed when you your self are logged in, not by viewing the forums from the outside. So poster can see ever ones's post and make comments about the build their using.

IE is starting to get messy with adding add-ons to the UA as Firefox extensions also adding cruft to the UA, for example GetGlue.

So build date compared to IE should probably really be the parity part here, not the addon's or people using the extra.* as noted in bug 581008.

I think Henri has good points, we should start somewhere. So with that in mind, there are bugs open for many issues. This not the only one. This should stay with the build date issue and what to do about it.

[Dale-bugzilla (dale-bugzilla)]

Ah, crap sorry, I thought this discussion was in the builddate bug. Ignore that part.

[Ben-bucksch (ben-bucksch)]

> I see no point in hiding helpful information when you're even more
> recognizable by fingerprinting fonts and addons.

The goal is to fix all of these leaks, one by one. See tracker bug 572650, and probably other bugs. The fact that we'd have to fix other places is not reason not to fix this one. A bit like saying "we have so many crashes, so why fix this one?".

This bug is *only* about stripping the minor Gecko version, from UA string and JS properties. (As far as I understand.) There are other bugs about the other issues.

---

There is another reason for this bug: Exposing the minor/patchlevel version of a browser is a serious security risk. It's basically telling the attacker exactly which security holes he may use. That makes an attack much more likely to a) succeed and b) be undetectable.

[Rsx11m-pub (rsx11m-pub)]

> (comment #15) And security by obscurity is a myth.

As said, I'm using this information to point out to users that they need to update there installed version, that's the best way to keep it safe and to make them learn that they have to do something on their own.

If you run into a malicious site with a drive-by exploit, it won't first check your user-agent string what you patch level is, it will simply try a couple of exploits in the hope that one or more of them will succeed.

[Ben-bucksch (ben-bucksch)]

> it will simply try a couple of exploits in the hope that one or more
> of them will succeed.

That's the stupid way. The smart way is to only try those that you are fairly sure will succeed.

Esp. if we build something like attack detection, or the company firewall/proxy has it.

[Ben-bucksch (ben-bucksch)]

Any, FWIW, this is a mis-application of "security by obsurity". The phrase says that one must not *rely* on obscurity for the sake of security. However, obscurity can very well *help* with security, it's an added bonus.

[Henri Sivonen (hsivonen)]

(In reply to comment #28)
> As said, I'm using this information to point out to users that they need to
> update there installed version,

Firefox has built-in functionality for alerting the user that there's an update available.

[Rsx11m-pub (rsx11m-pub)]

Well, guess what - users switch it off or ignore it...

The main question is if hiding that information brings sufficient benefit to
make fingerprinting more difficult to sacrifice the benefits for QA and support to determine which version a user is running. I think I've made my point clear.

[Reşat SABIQ (sabiq)]

(In reply to comment #14)
> For an administrator, this information is usually quite useful in enterprise
> settings (e.g., to identify users who don't update their laptops on a regular
> basis).

Admins can easily check %FIREFOX_HOME%/application.ini
(that could require a bit of extra effort, but not much).
These kinds of use-cases are not at all a justification for
giving such details to everybody in the universe.

> If a user is concerned of fingerprinting, there is general.useragent.override
> to make up whatever you want.
An average Joe isn't really going to update his override every few weeks. This is a much mentioned non-solution solution...

P.S. I have mixed feelings about the plethora of new bugs
which are previously discussed subsets of pre-existing bugs.
On the one hand, they are more specific and operational and
are finally getting knocked off the list
(big sigh of relief), on the other hand without a notification on
pre-existing bugs about these new subset bugs people who were
involved in prior discussions (and waiting anxiously for any
developments) got cut off. I think there's been great and
welcome progress (finally after 9-10 years) on this front,
but procedurally things look quite messy. Somebody will need
to close out all the previous tracking and super-set bugs
(such as 57555, 71569, etc.),
once the sub-set bugs are taken care of.

[Rsx11m-pub (rsx11m-pub)]

> (comment #33) Admins can easily check %FIREFOX_HOME%/application.ini
Not on machines which are maintained by the users themselves (laptops, etc.),
that's the stated use case where a direct access isn't readily available.

[Henri Sivonen (hsivonen)]

(In reply to comment #34)
> > (comment #33) Admins can easily check %FIREFOX_HOME%/application.ini
> Not on machines which are maintained by the users themselves (laptops, etc.),
> that's the stated use case where a direct access isn't readily available.

Your model assumes that users who are their own admins both 1) turn off Firefox's built-in update notification and 2) still update in response of an intranet page yelling at them (by detecting the patch level from the UA string). Seems like an edge case not worth catering for.

[Dale-bugzilla (dale-bugzilla)]

(In reply to comment #33)

> P.S. I have mixed feelings about the plethora of new bugs
> which are previously discussed subsets of pre-existing bugs.
> On the one hand, they are more specific and operational and
> are finally getting knocked off the list
> (big sigh of relief), on the other hand without a notification on
> pre-existing bugs about these new subset bugs people who were
> involved in prior discussions (and waiting anxiously for any
> developments) got cut off.

Well, bugs filed years ago had great ideas, but those never went anywhere and had no focus and a lot of cruft comments and maybe one or two developers driving direction. Now the can be focused with specific bug cases, which are being dealt with individually as new bugs as there is clearly a reason to fix them properly. These then are sometimes loosely tied together or duped to real bugs with patches after there is much needed progress in subset bugs.

[Rsx11m-pub (rsx11m-pub)]

> (comment #35) Your model assumes that users who are their own admins ...
It's no a model, it's happening in the real world and by professionals.

> 2) still update in response of an intranet page yelling at them
Of course not, they need to be approached by e-mail or in person where possible to convince them that it's for their own good. So, the UA is a screening tool.

Conditions on an enterprise/institutional level are different from the private setting, fingerprinting here is already possible just by the IP address being static of from a narrow range, thus providing a unique print. It's a trade-off between different interests, and help desks and administrators are using that information as it is available to avoid lengthy discussions with the user which version of what they are actually running. That's all I'm trying to motivate, not neglecting the opposing arguments stated in this bug.

[Reşat SABIQ (sabiq)]

(In reply to comment #34)
> > (comment #33) Admins can easily check %FIREFOX_HOME%/application.ini
> Not on machines which are maintained by the users themselves (laptops, etc.),
> that's the stated use case where a direct access isn't readily available.

Sounds like this use-case requires the business to write a little (startup) script that gathers %FIREFOX_HOME%/application.ini-based info, along with anything else necessary, and makes an HTTP(S) request to the company's website, where logging (or DB-based persistence) would do the same thing that UA checks are doing now. Or have a program silently download and install the apps required (i've had experience w/ uninstallations done in this annoying fashion). A bit extra effort, but nothing not doable.

Possibly, the user could be disallowed to do any installations except via intranet-based app installation requisitions w/ apps pushed onto the machine. Otherwise, if the employee tries to interfere with such admin software, then apparently the employee's manager should be notified (again, possibly automatically) to straighten the fellow up.

Besides, this is a special case, that shouldn't impede the interests of most users.

P.S. If mozilla gets itself into the business of trying to save some enterprises from writing some fairly simple (startup) scripts and tries to simplify HR matters for such enterprises, then THAT should be a separate enhancement bug to be dealt w/ separately from getting rid of minor version and Gecko build date. That enhancement bug could then ask for it to be configurable for this use-case. But again, that would cause fingerprintability mostly against organizations w/ this use-case, so they would then probably prefer to write shell scripts, extensions, other software etc. themselves to avoid that.
P.P.S. With regards to new-subset vs. pre-existing superset bugs, i do agree that subsets at least in appearance have proven to be easier to resolve. However, IMHO there's some room for improvement in making dependencies clear, or at the very least posting notifications in pre-existing (superset) bugs (to avoid cutting folks off)...

[Davemgarrett (davemgarrett)]

For what it's worth, the bigger problem comes down to the way we handle middle dot releases, i.e. the 'y' in x.y.z. If 3.6.4 were simply released as 3.7 instead of a mid-stream "minor release" then nobody would complain. The problem is that we built up a record of making x.y releases "major". This is what needs fixing. We need to be able to push out semi-major x.y releases more easily, possibly in a fashion with less user irritation than a major release but more than a minor.

And yeah, tangent topic and this bug is over.

[Shaver (shaver)]

It is always nice to have bright line indications of what is a "mistake in project management", but I think it's probably healthiest for the web for there to be robust competition between project management approaches. Beonex can choose its, and we can choose ours, and people can decide which they prefer.

[Dwitte (dwitte)]

At the time, there was talk of calling OOPP 3.7 and still pushing it as a minor release, if I recall. Having that kind of policy is something that should be discussed on mozilla.dev.planning. It doesn't change the fact that we have and will, whether inadvertently or not, break sites with security fixes in minor releases. And it doesn't change the fact that there's a benefit to users via up-to-date checking services. Security through obscurity has never been a fantastic idea, which simply leaves the fingerprinting argument.

My hunch is that the balance here will ever be in favor of dropping it.

[Dwitte (dwitte)]

And by ever, of course, I mean never.

[Davemgarrett (davemgarrett)]

Agreed.

[Ben-bucksch (ben-bucksch)]

Yeah, sorry for the slanderous tone about mismanagement.

I just want to respond to this:

> Security through obscurity has never been a fantastic idea

This is *not* security through obscurity. I already pointed that out in comment 30. "security through obscurity" means that you leave security holes open in the hope that nobody will discover them. In other words, obscurity is no *replacement* for security. However, obscurity *can* indeed help as an *added* bonus, everything else being equal. I argue that not openly advertizing which security holes you are vulnerable to (given that the UA string decision will not affect user update decisions, i.e. security doesn't change) is an "added bonus".
I also don't think that whether attackers use it today or not is an overriding reason, just that it's possible and would help them avoid unnecessary detection.

[Davemgarrett (davemgarrett)]

(In reply to comment #87)
True, but we could debate on the scale of whatever the "added bonus" is, and as I said at the beginning of this long winding bug, if we want to avoid this type of lingering security hole we need to focus on updating our damn users.

Regardless, this bug is supposedly resolved and I'm probably not the only person here getting an uptick in bugmail these days. Let this point of some agreement please be the end of this discussion, at least for now. ;)

[Reşat SABIQ (sabiq)]

I'm not asking for this discussion to be continued now, but FYI (in case this discussion is continued at some point):
https://bugzilla.mozilla.org/show_bug.cgi?id=589489#c6

[Dao (dao)]

Reopening, we've switched to rapid releases and aren't shipping new features in minor releases anymore.

[Dao (dao)]

Created attachment 598827
patch

- made it so that pre-release indicators are actually removed
- updated files js/src/config

this fixes bug 728797 and thereby bug 728610

[Gervase Markham (gerv-mozilla)]

Comment on attachment 598827
patch

>-`milestone.pl [--topsrcdir TOPSRCDIR] [--objdir OBJDIR] [--srcdir SRCDIR] --template [file list]` # will build file list from .tmpl files
>+`milestone.pl [--topsrcdir TOPSRCDIR] [--objdir OBJDIR] [--srcdir SRCDIR] --template [file list] --uaversion` # will build file list from .tmpl files

compare:

>+MOZILLA_UAVERSION=`$PERL $srcdir/config/milestone.pl -topsrcdir $srcdir -uaversion`

"--uaversion" or "-uaversion"?

sr=gerv on the principle; someone else needs to check the code.

Gerv

[Bzbarsky (bzbarsky)]

Comment on attachment 598827
patch

r=me on the HTTP bit

[Mh+mozilla (mh+mozilla)]

Comment on attachment 598827
patch

Review of attachment 598827:
-----------------------------------------------------------------

::: config/autoconf.mk.in
@@ +43,5 @@
> MOZILLA_CLIENT = 1
> target = @target@
> ac_configure_args = @ac_configure_args@
> MOZILLA_VERSION = @MOZILLA_VERSION@
> +MOZILLA_UAVERSION = @MOZILLA_UAVERSION@

That shouldn't be needed.

::: configure.in
@@ +8911,5 @@
>
> AC_SUBST(WIN_TOP_SRC)
>
> AC_SUBST(MOZILLA_VERSION)
> +AC_SUBST(MOZILLA_UAVERSION)

That shouldn't be needed. AC_SUBSTs are only needed when the value needs to be used in makefiles, which it isn't.

::: js/src/config/autoconf.mk.in
@@ +43,5 @@
> MOZILLA_CLIENT = 1
> target = @target@
> ac_configure_args = @ac_configure_args@
> MOZILLA_VERSION = @MOZILLA_VERSION@
> +MOZILLA_UAVERSION = @MOZILLA_UAVERSION@

That's not needed.

::: js/src/configure.in
@@ +5229,5 @@
>
> AC_SUBST(WIN_TOP_SRC)
>
> AC_SUBST(MOZILLA_VERSION)
> +AC_SUBST(MOZILLA_UAVERSION)

That's not needed.

[Dao (dao)]

Created attachment 598846
patch v2

addressed glandium's comments

[Dao (dao)]

http://hg.mozilla.org/mozilla-central/rev/0a7410527788

[Micah Gersten (micahg)]

Thank you for reporting this to Ubuntu. This has actually been fixed in Firefox 13 (trunk ATM). Please report any other issues you may find.

[Dolske (dolske)]

Backed out this (and bug 588909).

http://hg.mozilla.org/mozilla-central/rev/f7ccbfd0b7c6
http://hg.mozilla.org/mozilla-central/rev/d07998fb3530

Discussion over in bug 588909, please, since this was just collateral damage from the primary backout. :)

[Dao (dao)]

http://hg.mozilla.org/mozilla-central/rev/be559203ece8

This was backed out for convenience, it doesn't depend on bug 588909.

[Rsx11m-pub (rsx11m-pub)]

Well, the main thing is that bug 588909 conveniently caused bug 728610, otherwise it's questionable if this would have been implemented so quickly, especially given the new rapid-release system which renders a lot of the discussion on the previous branch-based reasoning stated here moot to some extent... correct? ;-)

[Dao (dao)]

Bug 588909 surely accelerated this, although bug 728610 was an issue for Fennec before that.

[Rsx11m-pub (rsx11m-pub)]

... yes, given that they performed that UA change before Firefox, but essentially it's the same reason, so that doesn't really change much in the order of events or argumentation (meaning, the fix here resulted from the Gecko-token change, thus the rationale of comment #97 is valid and not just for convenience).

[Dolske (dolske)]

Oh, derp, I should have looked harder. I didn't realize this patch was changing the Gecko/X _and_ rv:X stings.

OTOH, I'd suspect this ends up breaking our Firefox landing/first run pages, which check to see if you're actually running the latest build or not.

Did you test to see if that's a problem? And/or give webdev a heads up? I'd expect that Mozilla's own sites/metrics are the _only_ place on the web where this should be a valid concern.

[Dao (dao)]

(In reply to rsx11m from comment #101)
> ... yes, given that they performed that UA change before Firefox, but
> essentially it's the same reason, so that doesn't really change much in the
> order of events or argumentation (meaning, the fix here resulted from the
> Gecko-token change, thus the rationale of comment #97 is valid and not just
> for convenience).

I'm not sure what your point is. Backing this out still wasn't necessary and it still fixes an issue for fennec.

(In reply to Justin Dolske [:Dolske] from comment #102)
> Oh, derp, I should have looked harder. I didn't realize this patch was
> changing the Gecko/X _and_ rv:X stings.
>
> OTOH, I'd suspect this ends up breaking our Firefox landing/first run pages,
> which check to see if you're actually running the latest build or not.
>
> Did you test to see if that's a problem? And/or give webdev a heads up? I'd
> expect that Mozilla's own sites/metrics are the _only_ place on the web
> where this should be a valid concern.

I get "Thank you for trying a nightly build and helping improve future versions of Firefox" here (http://www.mozilla.org/projects/firefox/prerelease.html). Might be because they sniff the Firefox token.

[Dolske (dolske)]

> (In reply to Justin Dolske [:Dolske] from comment #102)
> > OTOH, I'd suspect this ends up breaking our Firefox landing/first run pages,
> > which check to see if you're actually running the latest build or not.
>
> I get "Thank you for trying a nightly build and helping improve future
> versions of Firefox" here
> (http://www.mozilla.org/projects/firefox/prerelease.html). Might be because
> they sniff the Firefox token.

Pretty sure we don't do any special "are you current" checking on the nightly pages; I don't know about Aurora or Beta.

I was actually thinking of Release builds and security updates, but I see the patch doesn't actually match the original bug comments nor current title. (Which seems to have mutated somewhere along the 100 comments which I desperately want to avoid reading. Using a new bug would have been MUCH better -- mutating complex or contentions bugs with histories just never works out well. Context matters!)

Specifically, the previous history of this bug was more about exposing a version number like "rv:3" or "rv:3.6" instead of "rv:3.6.20". Now we're just dropping any trailing, say, "a2", "b1", or "pre3". So now "rv:13.0a1" becomes "rv:13.0" and "rv:13.0.9pre42" becomes "rv:13.0.9" (which is largely moot, we don't make builds like that).

As long as first security update for the Release build still has "rv:13.0.1", the issue I raised in comment 102 is quite unlikely to be be a problem.

And if someone still wants to push for dropping everything but the "13.0", then please file a new bug. Or get your debate on over in the Seamonkey-specific bug 728952.

Finally, re:CCing Dan Witte just because he should suffer too. ;-D

[Dao (dao)]

(In reply to Dão Gottwald [:dao] from comment #103)
> I get "Thank you for trying a nightly build and helping improve future
> versions of Firefox" here
> (http://www.mozilla.org/projects/firefox/prerelease.html). Might be because
> they sniff the Firefox token.

Actuallly it's because we load http://www.mozilla.org/projects/%APP%/%VERSION%/whatsnew/, there's no need to sniff.

(In reply to Justin Dolske [:Dolske] from comment #104)
> Specifically, the previous history of this bug was more about exposing a
> version number like "rv:3" or "rv:3.6" instead of "rv:3.6.20". Now we're
> just dropping any trailing, say, "a2", "b1", or "pre3". So now "rv:13.0a1"
> becomes "rv:13.0" and "rv:13.0.9pre42" becomes "rv:13.0.9" (which is largely
> moot, we don't make builds like that).

I think you're misunderstanding the patch. Milestone.pm exposes $major.$minor.$mini.$micro and this patch takes $major.$minor and strips of any alpha/beta indicators. That's unless I'm missing something...

[Rsx11m-pub (rsx11m-pub)]

(In reply to Justin Dolske [:Dolske] from comment #104)
> Or get your debate on over in the Seamonkey-specific bug 728952.

Err, no please - that bug is for SeaMonkey to decide whether or not to follow this step, it's application specific and hence not intended for Gecko discussions.

(In reply to Dão Gottwald [:dao] from comment #103)
> it still fixes an issue for fennec.

That was my point, the cause was the change in Fennec prompting bug 728610 in the first place, thus the need for this specific bug was the consequence of that change, accelerated by Firefox following Fennec. Thus, the cause/effect relation was upside down in your argumentation, and the solution for Fennec might have been backing out their patch in sync with bug 588909.

Anyway, I'm a bit confused why Fennec dominates the other Mozilla applications in this way, but that would probably be more a discussion for bug 588909.

[Dao (dao)]

I said nothing about cause and effect. I said this bug doesn't depend on bug 588909, which http://hg.mozilla.org/mozilla-central/rev/be559203ece8 proves to be true.

[Rsx11m-pub (rsx11m-pub)]

I wasn't talking about technical dependency in the sense of one bitrotting the other, but let's stop mincing words...

[Dao (dao)]

Created attachment 599958
Android-specific patch for aurora and beta

Here's a slightly cut down version of patch that only affects the Android-specific Gecko token in order to fix zimbra.

[Akeybl (akeybl)]

Comment on attachment 599958
Android-specific patch for aurora and beta

[Triage Comment]
Android-specific change that prevents a website regression in Native Fennec caused by recent UA changes. Approving for Aurora 12 and Beta 11.

[Dao (dao)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/a8fa3bbd301c
https://hg.mozilla.org/releases/mozilla-beta/rev/0517a93b8cdb

[Vic-garin (vic-garin)]

It still showing in latest nightly when I ran a test at https://panopticlick.eff.org

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:13.0) Gecko/20120226 Firefox/13.0a1

Notice it is showing a1.

Its also showing the date of build?

[Dao (dao)]

(In reply to Vic from comment #112)
> Notice it is showing a1.

bug 728831

> Its also showing the date of build?

bug 588909

[Antoine-mechelynck-gmail (antoine-mechelynck-gmail)]

Similarly for SeaMonkey (ID:20120226003024):
Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120226 Firefox/13.0a1 SeaMonkey/2.10a1

rv:13.0 (this bug) OK
Gecko/20120226 Firefox/13.0a1 SeaMonkey/13.0a1 (other bugs if any, probably including those listed under comment #113).

I see that there is a Fennec-specific patch which I cannot test (comment #109 and 110). Please test it as appropriate before setting VERIFIED.

[Ioana-budnar (ioana-budnar)]

Verified on the 20120305181207 builds:
Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20100101 Firefox/11.0
Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20100101 Firefox/11.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20100101 Firefox/11.0

The above UAs are displayed in http://www.delorie.com:81/some/url.txt.

[Djcater+bugzilla (djcater+bugzilla)]

(In reply to Ioana Budnar [QA] from comment #115)
> Verified on the 20120305181207 builds:
> Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20100101 Firefox/11.0
> Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20100101 Firefox/11.0
> Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20100101
> Firefox/11.0
>
> The above UAs are displayed in http://www.delorie.com:81/some/url.txt.

I've reset the status-firefox11 flag from verified to fixed. I think this is correct, but please let me know if I've made a mistake. Reasoning:

1. The aurora and beta checkins were mobile-only (comment 109). You have verified using desktop builds.
2. The first release of a major version has the form X.Y anyway (not X.Y.Z) so you can't tell from that whether this is fixed or not.

[Ioana-budnar (ioana-budnar)]

(In reply to Daniel Cater from comment #116)
> I've reset the status-firefox11 flag from verified to fixed. I think this is
> correct, but please let me know if I've made a mistake. Reasoning:
>
> 1. The aurora and beta checkins were mobile-only (comment 109). You have
> verified using desktop builds.
> 2. The first release of a major version has the form X.Y anyway (not X.Y.Z)
> so you can't tell from that whether this is fixed or not.

Daniel, this issue is fixed both for mobile and desktop. The other verifications were also made on X.Y versions since none of the builds in beta, aurora and central are ever X.Y.Z. When they get release, if an X.Y.Z version is released, I will also verify this bug on that version.

[Ioana-budnar (ioana-budnar)]

Verified as fixed on:
Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20100101 Firefox/12.0
Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/12.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20100101 Firefox/12.0
BuildID: 20120314195616

[Eshepherd (eshepherd)]

Docs updated:

https://developer.mozilla.org/en/Gecko_user_agent_string_reference

Mentioned on Firefox 13 for developers.

[D-b5gzilla-t (d-b5gzilla-t)]

(In reply to Eric Shepherd [:sheppy] from comment #119)
> Docs updated:
>
> https://developer.mozilla.org/en/Gecko_user_agent_string_reference
>
> Mentioned on Firefox 13 for developers.

This bug is fixed on Firefox 11
| status-firefox11: verified
| status-firefox12: verified
and it should be on "Firefox 11 for developers" page I think.

[Ioana-budnar (ioana-budnar)]

Verified on Firefox 13.0.2 (Firefox 13 is the first one with 13.0.x versions since this bug was fixed). The User Agent for Fx13.0.2 is:
Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20100101 Firefox/13.0.2

The UAs for other current versions are:
Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20100101 Firefox/14.0
Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120708 Firefox/15.0a2
Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/16.0 Firefox/16.0