Closed Bug 572659 Opened 14 years ago Closed 12 years ago

Don't expose the Gecko patch level (13.X.Y) in the UA string, only show the major version (13.X)

Categories

(Core :: Networking: HTTP, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla13
Tracking Status
firefox11 --- verified
firefox12 --- verified

People

(Reporter: hsivonen, Assigned: dao)

References

(Blocks 1 open bug, )

Details

(Keywords: dev-doc-complete, privacy, verifyme, Whiteboard: [parity-IE][qa!])

Attachments

(3 files, 1 obsolete file)

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.
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).
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.
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).
(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.
Whiteboard: [parity-IE]
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.
#2 in comment 5 was also filed separately as bug 572661
Depends on: 572661
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.
(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.
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.
(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.
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)
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)
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.
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.
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.
(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.
(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?
Whiteboard: [parity-IE] → [parity-IE][non-parity-WebKit]
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?
(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.
> (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...
(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.
(In reply to comment #21)
> Microsoft is getting rid of that stuff in IE9.

We may too -> bug 581008
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.
Whiteboard: [parity-IE][non-parity-WebKit] → [parity-IE]
I had only added it due to the [parity-IE] tag which was already present.  ;-)
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.
Ah, crap sorry, I thought this discussion was in the builddate bug.  Ignore that part.
> 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.
> (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.
> 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.
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.
(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.
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.
(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.
> (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.
(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.
(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.
> (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.
(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)...
Of, course, removing the patch level makes it impossible, e.g. for Farmville to warn people when using FF 3.6.4 that it causes the game to fail - or of course of doing specially-targeted web-based help for people who have a version with OOPP or not - and same for future features shipped in patch-level updates (yes, the plan seems to be to do that more often in the future).

Also, we have a rather large amount of people who turn off updates or don't run the browser with privileges allowed to install updates, and warning people on the default SeaMonkey home page that a newer version is available has helped a lot of people so far - that all will stop working with this approach and users will be left in the cold.

It's a tradeoff, of course, but I am unconvinced that the assumed privacy intrusion and fingerprintability is that high with exposing the patch level. IMHO, more than 2/3 of all proposed anti-fingerprinting measures regarding UA strings are paranoid and on the wrong side of the tradeoff. But that may be just me.
(In reply to comment #38)
> 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)...

Please no more ranting about this, the bug process, etc here or elsewhere.  Take it to the newsgroups.  You voice has been heard already, no need for duplicate comments.
Blocks: 584683
(In reply to comment #29)
> > 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.

rsx11m is right, apparently "the stupid way" is good enough in all the attacks I've investigated. You are right that in theory version sniffing could lead to less detectable attacks, but in practice about the most I've seen is IE vs "Netscape"(!) sniffing so they can decide whether to use ActiveX or a plugin. Some of the Metasploit attacks include platform sniffing for Win vs. Mac vs. Linux, but the only time I've seen those in the wild the Mac and Linux branches were snipped.

This is a tough call. Most users are up-to-date and the patch level provides no additional identifying information. For the ones who aren't the patch level provides a little bit of information to attackers, a little identifying information, but also a boon for support sites, nagging admins, and the occasional site with a transitory regression problem (e.g. Farmville).
(In reply to comment #3)
> (e.g. distinguishing Firefox 3.6.4 and 3.6.6 can be easily done by
> loading resource:///greprefs/all.js as a script).

Why doesn't all.js (and other pref files) start with a '#' line as the user's prefs.js does? We added that specifically to frustrate loading the file as a script should some other bug expose the profile directory. I suppose the theory might have been that you know the patch-level anyway from the UA so therefore an attacker already knows what the content is, but that's a circular argument.

If we fix that it'd be nice to make it indistinguishable between files with a syntax error and an error because the file doesn't exist (so that if you're spoofing the UA a page can't test for all-thunderbird.js vs. firefox.js or whatever).
Blocks: 586165
Blocks: 588909
Attached patch patch (obsolete) — Splinter Review
Here we go. This defines a MOZILLA_UAVERSION which configure.in generates as major.minor. This is valid for 2.0 (but obviously not for 1.9.3). It doesn't strip off the 'b5pre' bit, so betas get their day in the sun.

Whether to do this is unclear to me... I'm not worried about things like AMO or the addons manager, there are other ways for them to get this data. I do worry about cases like Farmville. Perhaps shaver can weigh in here; I can be certain he's thought about it. (See also bug 588905.)
Assignee: nobody → dwitte
Status: NEW → ASSIGNED
Attachment #467621 - Flags: superreview?
Attachment #467621 - Flags: review?(ted.mielczarek)
Attachment #467621 - Flags: superreview? → superreview?(jst)
Depends on: 589037
Comment on attachment 467621 [details] [diff] [review]
patch

Per comment #41 and others, has it been established that this is wanted?
Loosing the minor version (especially along with the build date) appears
to be still disputed.
Comment on attachment 467621 [details] [diff] [review]
patch

There is no point to truncating off the patch level of just Gecko. You would have to do so for the application at the same time, as well as drop the build date. The three are directly connected; knowing one implies the others, thus you won't lower fingerprintability unless you get all three at once.
And while the security issue is largely not as applicable as some say, it too would require that all three go away at once.
That's bug 588905 for Firefox. So, if it's up to the applications whether or not to truncate their application strings, will it be consequently up to them as well to decide whether or not the Gecko version should be truncated?

Firefox may or may not want this, but reading comment #39, SeaMonkey apparently won't, and so may others.
If you want the desired effects, this can't really be done piecemeal. I think having many different bugs for all of this as we do now is counterproductive.
(In reply to comment #45)
> There is no point to truncating off the patch level of just Gecko.

Truncating the Firefox version goes hand in hand with this, yes.

> date. The three are directly connected; knowing one implies the others, thus
> you won't lower fingerprintability unless you get all three at once.

This isn't just about fingerprintability. We could drop build date but not minor versions.

(In reply to comment #47)
> That's bug 588905 for Firefox. So, if it's up to the applications whether or
> not to truncate their application strings, will it be consequently up to them
> as well to decide whether or not the Gecko version should be truncated?

My patch here doesn't provide for that, but it trivially could.

> Firefox may or may not want this, but reading comment #39, SeaMonkey apparently
> won't, and so may others.

That's their decision, they're free to use whatever versioning they like.

(In reply to comment #48)
> If you want the desired effects, this can't really be done piecemeal. I think
> having many different bugs for all of this as we do now is counterproductive.

The purpose is to separate out the discussion. There are different tradeoffs and breakage scenarios for each change. Bug 586165 is what puts it all in context.
(In reply to comment #49)
> This isn't just about fingerprintability. We could drop build date but not
> minor versions.

Yes, but that's not this bug or patch. That's bug 572661. This one is more about fingerprintability.

> The purpose is to separate out the discussion.

The separation has made the discussion a bit diffuse and I don't think Bugzilla's dependency system is precise enough for the planning here as-is because it doesn't allow for one-way dependency or mutually-exclusive options. An example of this is the above part of this reply. Dropping the Gecko minor revision requires dropping the application minor revision and Gecko build date to be useful (to fully hide the minor revision). Dropping the build date can be done by itself to get a useful effect (to reduce bad sniff surface). I think it would make more sense to do one patch with respect to this topic instead of having a patch that by itself isn't useful, that's all, though that's just my opinion

That being said, while there is an argument for this specific bug I don't see how it wins out in a cost-benefit analysis.
(In reply to comment #50)
> having a patch that by itself isn't useful, that's all, though that's just my
> opinion

Well, we're not going to land this bit by bit. :)

> That being said, while there is an argument for this specific bug I don't see
> how it wins out in a cost-benefit analysis.

But together with Firefox major version and dropping build id, you do?
(In reply to comment #51)
> > That being said, while there is an argument for this specific bug I don't see
> > how it wins out in a cost-benefit analysis.
> 
> But together with Firefox major version and dropping build id, you do?

No. Dropping all three would have some benefit, but with a big headache. Dropping just the build ID would have some benefit, but not that much of a headache.
Can you elaborate on what you think the headaches would be? Seeking information here -- specifics are key.
Some of the issues have been brought up in the build date bug, ie support, testing/bugzilla and AMO would suffer if all 3 were implemented as suggested, together would be bad without some backup/workaround plan to still do what do now.  Though were mainly just talking the UA here, not the JS API, and hopefully not the about:about screen.  We need is a solid work around plans for each issue, otherwise I don't see these issues going anywhere together but to the theoretical.
Removal of all announcement of minor versioning:

Pro:
+ Less server-side fingerprintability
+ Slightly less data in each HTTP request
+ Less bad UA sniffing surface
+ Theoretical resistance to known exploits by minor version (dubious value)

Con:
- Less accurate AMO compatibility checking; some addons do require a specific minor update that fixes or adds something and users could have an incompatibility error on an install that shouldn't be allowed if the exact version is not detected. (bug 589037 was filed for discussion on that end) Addons are a prime Firefox raison d'être, thus we don't want to add ways to confuse users here.
- No longer obvious that a (regular) user needs to update on Bugzilla or support; this seems minor but this will make our lives here and on SUMO much harder. It's one extra question for important information to ask potentially annoyed users who aren't always talkative.
- Enterprise admins will have a harder time tracking their users' updates (comment 14)
- The creation of some new system to work around the above problems would add quite a bit of complexity, whereas we currently have a system that does work and is simple.
- Contrary to past procedure, 3.6.4 was not really a normal "minor" update and discussion has stated that we can expect future maintenance releases with big changes. Dropping support for detection via UA string thus drops more than is implied; someone could come up with a valid reason for detecting one of these updates. (not just on AMO, Bugzilla, or support) In other words, newer policy on handling minor versions could lead to unforeseen problems if we continue to treat minor versions as purely minor.
- Some browser statistics gathering would suffer (though maybe not Mozilla's own via update pings)
- Non-zero risk of breaking some sites using bad UA sniffing scripts


Removal of just the build date, but keeping primary minor versioning:

Pro:
+ Less bad UA sniffing surface (some known problems fixed here)
+ Slightly less data in each HTTP request
+ Less fingerprintability in nightlies, but no change in stable or betas (debatable value)

Con:
- Won't know exact versions for bugs or support requests about nightlies and won't be able to tell nightly users to update to fix recent issues. This will jump in importance once Firefox 4 is branched and Trunk doesn't change its version that often again.
- Non-zero risk of breaking some sites using bad UA sniffing scripts
To vaguely quantify the main point of server-side fingerprintability (that this bug was filed largely for) I would call bug 581008 a big rock, bug 572661 a rock that affects only a small population that is already highly fingerprintable by virtue of major version, and this bug (removing all 3 minor versioning points in the UA string) a pebble or grain of sand if users actually update (another matter entirely). 100% fingerprint resistance is impossible and some other bugs that would get us closer are rejected for various important reasons. Once we start talking client-side fingerprintability this bug then becomes infinitesimally small in value behind the mountain that is plugins and Flash exposing fonts and everything else in the known universe.

Important to the cost-benefit analysis is the fact that working around all known and _unknown_ hurdles is itself a bigger cost than people are thinking. Anyone here really want to write and maintain some sort of user prompting and/or at least potentially confusing system for a whitelist for just telling a site the browser's full version? Even just a simple JS API that is unrestricted is more that has to be added and used, adding complexity here and in consumers that we just don't need. Even if it's doable, it's a headache waiting to happen.

Also note, the potential security argument is listed in comment 55 because it was made by others but I don't personally side with it that much. (read above)

(sorry for repeating myself a bit, but Dan wanted more specifics ;)
(In reply to comment #49)
> (In reply to comment #47)
> > Firefox may or may not want this, but reading comment #39, SeaMonkey apparently
> > won't, and so may others.
> 
> That's their decision, they're free to use whatever versioning they like.

Since this is Core code, I would assume that the Gecko-rv truncation applies equally to all applications, unless the patch provides for a switch, correct?

> (comment #56) Once we start talking client-side fingerprintability this bug then
> becomes infinitesimally small in value behind the mountain that is plugins and
> Flash exposing fonts and everything else in the known universe.

I can sure agree with that statement...
(In reply to comment #56)
> Once we start talking client-side fingerprintability this bug then
> becomes infinitesimally small in value

And if we take into account that it's trivial to do an XHR or iframe request and send all client-side data to the server as long as JS is enabled, I wonder how large the overall win really is.

(In reply to comment #55)
> Pro:
> + Less bad UA sniffing surface

I'd call the value of that dubious at best as well, I've not really heard about bad UA sniffing that is concerned with minor versions reported.
What I have heard as a problem there is the "pre" suffix as a problem (who the hell had the idea this could mean being a Palm Pre?), but I think the current patch wouldn't even address that interesting casem.
(In reply to comment #58)
> (In reply to comment #55)
> > Pro:
> > + Less bad UA sniffing surface
> 
> I'd call the value of that dubious at best as well, I've not really heard about
> bad UA sniffing that is concerned with minor versions reported.

It is possible to screw up sniffing on the dot something part, for example reading 3.5.10 as 3.5.1 because the sniffing script expects only three digits. I vaguely remember this happening at least once.

> What I have heard as a problem there is the "pre" suffix as a problem

Getting rid of all UA string minor versioning fully would imply doing both bug 572661 and bug 582672, yes. (it looks like the current patch here would truncate to x.y cutting off any "pre", unless I'm mistaken)
(In reply to comment #54)
> now.  Though were mainly just talking the UA here, not the JS API, and
> hopefully not the about:about screen.  We need is a solid work around plans for
> each issue, otherwise I don't see these issues going anywhere together but to
> the theoretical.

Totally agree that we need to understand what would break, not least of which so that we can determine whether those concerns are common to other sites in the wild. For what AMO is doing the information can still be obtained via JS, and as Wenzel leads me to believe, that's what currently happens. But maybe I misunderstood?
(In reply to comment #55)
> Removal of all announcement of minor versioning:

Thanks! Awesome summary.

Note that my main reason for this change is not fingerprintability -- it's that we shouldn't expose information that isn't relevant to a vast majority of the web, *in the UA string*. There are other ways they can determine this currently if they want to, and every bit we expose is more surface for people to get it wrong. Specifically, the Gecko version is removing an entire version part for 2.0 (from e.g. 1.9.3), and before 1.9.0 it was also two parts. So people that are sensitive to that have already had trouble.

With regard to the 'but Flash can fingerprint anyway!' and related arguments, those are separate bugs that we can work (and are working) on. There's a strong push to make privacy better, and interpreting this bug in isolation is counterproductive. The issue is that we need to make UA changes *now* for Firefox 4, and that we should avoid thrashing it in future (even for 5) if there's not a strong reason to. In the absence of other changes, this bug alone would not be significant enough to justify that.

(In reply to comment #57)
> Since this is Core code, I would assume that the Gecko-rv truncation applies
> equally to all applications, unless the patch provides for a switch, correct?

Sorry, yes -- I thought you were referring to the Firefox / Seamonkey product version.

> 
> > (comment #56) Once we start talking client-side fingerprintability this bug then
> > becomes infinitesimally small in value behind the mountain that is plugins and
> > Flash exposing fonts and everything else in the known universe.
> 
> I can sure agree with that statement...

(In reply to comment #58)
> What I have heard as a problem there is the "pre" suffix as a problem (who the
> hell had the idea this could mean being a Palm Pre?), but I think the current
> patch wouldn't even address that interesting casem.

That's bug 582672. (The patch here doesn't address that.)
(In reply to comment #59)
> It is possible to screw up sniffing on the dot something part, for example
> reading 3.5.10 as 3.5.1 because the sniffing script expects only three digits.
> I vaguely remember this happening at least once.

Opera, as the first browser to reach version 10, ran in to this issue. See: http://dev.opera.com/articles/view/opera-ua-string-changes

It's really too bad that people can't do proper sniffing.
(In reply to comment #61)
> (In reply to comment #55)
> > Removal of all announcement of minor versioning:
> 
> Thanks! Awesome summary.
> 
> Note that my main reason for this change is not fingerprintability -- it's that
> we shouldn't expose information that isn't relevant to a vast majority of the
> web, *in the UA string*. There are other ways they can determine this currently
> if they want to, and every bit we expose is more surface for people to get it
> wrong.

I agree, the sniff surface argument is probably more important than fingerprintability in this instance.

> With regard to the 'but Flash can fingerprint anyway!' and related arguments,
> those are separate bugs that we can work (and are working) on.

Any Flash or other plugin issues are client-side where fingerprinting resistance is much much harder. (though, what Flash exposes can be stopped with Flashblock or built-in click-to-play if we ever get it) Server-side is another matter and arguably more important because it's transparent to the user.

(In reply to comment #62)
> It's really too bad that people can't do proper sniffing.

Unfortunately, yeah, sniffing in general is frequently messed up. It's usually a bad idea. We could bend over backwards to try and resist it but at some point the backwards-bending will be more annoying than its benefits. :)
(In reply to comment #61)
> There are other ways they can determine this currently if they want to

How would you suggest AMO or Bugzilla or SUMO do things? What's available via JS in navigator.userAgent would be the same as what's done for the HTTP request. (mentioned in another bug) We'd need to add something new as was suggested by others.
(In reply to comment #64)
> How would you suggest AMO or Bugzilla or SUMO do things? What's available via
> JS in navigator.userAgent would be the same as what's done for the HTTP
> request.

Indeed you're right (I was under the impression AMO used a different method for sniffing minor version, but that's incorrect).

AMO would simply lose the ability to sniff minor version. The addons manager would have to do it, which means AMO might offer an incompatible version. I hear that it's extremely rare for an addon to depend on minor version:

<Archaeopteryx> most add-ons are major.version.0-major.version.*, only a small group starts or end between those

Bugzilla and SUMO would have to gather information via about:support. For SUMO, this is what's being proposed as recommended practice anyway, though I'm not really a part of those discussions.
(In reply to comment #65)
> I hear that it's extremely rare for an addon to depend on minor version

The number one extension, Adblock Plus, currently requires a minimum of Firefox 3.0.12 and has for a while. That's not rare. ;)

Also, there's Lorentz and similar not-really-minor versions that may happen in the future. It would be nice if the minor version could be fully discounted, but it can't.

> Bugzilla and SUMO would have to gather information via about:support.

Some users are hard to help. Asking for information from some is an uphill battle. Some don't ever reply to you and only read your first reply to them. If you don't have this very critical information from the get-go you're already behind and you have an extra step to go through, which also wastes time and energy.

Also, some users don't know what they're doing at all. I can't tell you how many times I or someone else has asked a user to fetch some basic information so they can be helped and they typed it in wrong or pasted the wrong thing or couldn't follow the instructions at all. Sometimes it's a language barrier or other times they just barely know how to use their computer. Many users simply can't grok the way version numbers are written and all sorts of weird and wrong version numbers are said by users that clearly don't match their UA string. At least with the UA string right now we have a decent starting point.
(In reply to comment #66)
> 
> Some users are hard to help. Asking for information from some is an uphill
> battle. Some don't ever reply to you and only read your first reply to them. If
> you don't have this very critical information from the get-go you're already
> behind and you have an extra step to go through, which also wastes time and
> energy.
> 
> Also, some users don't know what they're doing at all. I can't tell you how
> many times I or someone else has asked a user to fetch some basic information
> so they can be helped and they typed it in wrong or pasted the wrong thing or
> couldn't follow the instructions at all. Sometimes it's a language barrier or
> other times they just barely know how to use their computer. Many users simply
> can't grok the way version numbers are written and all sorts of weird and wrong
> version numbers are said by users that clearly don't match their UA string. At
> least with the UA string right now we have a decent starting point.

True, that's why there are services like http://www.supportdetails.com/ which then of course would become less usefull after all this fingerprintability-reducing.
How about making up for it by improving about:support?
Attachment #467621 - Flags: superreview?(jst)
Attachment #467621 - Flags: review?(ted.mielczarek)
Not gonna do this.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
> Not gonna do this.

Please give reasons and who decided that.
FWIW, it's possible to make one-off solutions for bugzilla, AMO and SUMO, based on hostname/domain, in a pref. Simplest and a bit ugly would be make the UA string longer, if the domain is whitelisted. Or we could make a JS property that only these sites can access.
IMHO, this bug wasn't as important as bug 572659, or bug 583181, so it's definitely OK in my book to focus on those first.

(In reply to comment #70)
> Or we could make a JS property
> that only these sites can access.
I do agree that in the long term a restricted JS property looks like a better option. Moreover, this bug is also inter-dependent with bug 583181, and i think it's premature to wontfix this bug w/o resolving bug 583181 first. And once bug 583181 is resolved, all the reasons given here about why minor version detecting matters could be addressed via buildID as well (though that isn't guaranteed to happen), and if so there wouldn't be any reason to keep minor version in UA string or any other globally visible property anymore (which could allow Firefox 4 UA string format to last at least 10 years, w/o having to deliberate whether to do another change for Firefox 5 or 6).

P.S. I have to say also that i think it's a wrong policy to release non-minor updates in minor versions (see Lorentz). I think that policy is begging to be reviewed. If that policy was to stand, then it begs a versioning change, something along the lines of the following new bug 589489.
(In reply to comment #68)
> Not gonna do this.

Does this decision include a decision to continue to distinguish nightlies by appending e.g. "b5pre" to the Gecko version and the Firefox version? Or should I file another bug about removing that bit (in order to make the nightlies more representative of how a release would behave in face of sniffers and in order to avoid getting sniffed as Palm Pre)?
(In reply to comment #72)
> Does this decision include a decision to continue to distinguish nightlies by
> appending e.g. "b5pre" to the Gecko version and the Firefox version? Or should
> I file another bug about removing that bit (in order to make the nightlies more
> representative of how a release would behave in face of sniffers and in order
> to avoid getting sniffed as Palm Pre)?

The "pre" part (at least) is bug 582672.
(In reply to comment #69)
> > Not gonna do this.
> 
> Please give reasons and who decided that.

The rationale here was that we have broken sites with minor releases before, and will continue to do so given our willingness to land major non-user-facing features in minor updates (see also: OOPP). These sites have a legitimate case for detecting users of broken versions and taking appropriate action.

The best argument for removing it is a) fingerprinting and b) security considerations. dveditz (security group) suggested that the latter is not that relevant in practice: cases he's seen in the wild involve simply trying every known vulnerability and seeing if one sticks. Detection beyond that probably isn't a big concern, but if there's evidence to the contrary, that's definitely interesting. The flipside of this is that minor version is legitimately used by third-party up-to-date checking services, which probably makes the net usefulness positive.

The fingerprinting concern isn't all that severe because 90% of our users are on the latest minor release within two weeks of shipping. (This does suck for the other 10%, though, and that's worth bearing in mind.) And the liability of including it is basically zero (unlike build date), because it changes so often that nobody could depend on it being a particular value.

My opinion here is that we could revisit this in future, and if we did it would be in concert with dropping Firefox minor version. Any such consideration has to carefully weigh the cost and benefit.
(In reply to comment #74)
> The rationale here was that we have broken sites with minor releases before,
> and will continue to do so given our willingness to land major non-user-facing
> features in minor updates (see also: OOPP).

Forgive me my tone, but this sounds to me like saying:
"Given our willingness to shoot ourselves in the feet, we have to have to wear bullet-proof steel shoes, despite all the inconvenience, and all the alarms caused 10% of the time."

IMHO, this issue is a bug (despite no-discussion treatment given to it in bug 589489), and will have to be re-evaluated sooner or later. Major features is not what minor updates are for (which is things like security issues, and memory leaks).

That said, i agree that build date issue is much more important than this one, and in principle this one might be livable with, because at least fingerprintability here is caused by the user not performing expected updates that they really should be performing (there are no excuses like that w/ build date, and privacy damage there is huge for non-Windows users).
(In reply to comment #75)
> Forgive me my tone, but this sounds to me like saying:
> "Given our willingness to shoot ourselves in the feet, we have to have to wear
> bullet-proof steel shoes, despite all the inconvenience, and all the alarms
> caused 10% of the time."

Not at all, it's just being practical.

> IMHO, this issue is a bug (despite no-discussion treatment given to it in bug
> 589489), and will have to be re-evaluated sooner or later. Major features is
> not what minor updates are for (which is things like security issues, and
> memory leaks).

I don't think your characterization of what happened in bug 589489 is accurate. You were just encouraged to take the discussion to a specific newsgroup, since bugzilla isn't the right forum for broad discussions of that nature. Discussion is always welcome.

> That said, i agree that build date issue is much more important than this one,
> and in principle this one might be livable with, because at least
> fingerprintability here is caused by the user not performing expected updates
> that they really should be performing (there are no excuses like that w/ build
> date, and privacy damage there is huge for non-Windows users).

Well, in general, they're the same information (with exceptions, of course) -- each release has a 1-1 correspondence with a build ID. The difference is that build ID has caused us problems before, whereas this is more of a privacy concern.
(In reply to comment #76)
> Not at all, it's just being practical.
I'm all for being practical, but that's not being practical. "Being lazy" or "being sloppy" is more like it: we don't want to call it a major release, even though the UI has changed a bit (new preference check-box, new plugin crash report widget), we don't what to wait until the next major release, and we don't want to come up w/ something in between minor and major releases (which is exactly what this was), so let's just ship it as a minor update (even though it's not).
Anyway, i guess the notion needs some time to sink in...

> I don't think your characterization of what happened in bug 589489 is accurate.
> You were just encouraged to take the discussion to a specific newsgroup, since
> bugzilla isn't the right forum for broad discussions of that nature. 

I have stated in that bug why forum is not the right venue for such a discussion, but please discuss it in a forum if you think it is.

> The difference is that
> build ID has caused us problems before, whereas this is more of a privacy
> concern.
FWIW, for me it's about non-Windows users having an option of masking their UA as a Windows-based UA for similar privacy reasons (w/o the hassle of having to  update this and that every few weeks).
Theoretically, even security and memory leak fixes could have adverse effects for normal sites. Not sure how likely though or if this ever happened before.
It has, but I'm less worried about that case because we tend to fix it very fast. Fixes for major changes like OOPP are less likely to be easy and hence fast, though I'm sure there are (or will be) counterexamples in both cases.
Minor releases should *only* fix security bugs and serious bugs (I'd even go so far that this is the definition of a minor release).
Shipping a feature or bigger change in a minor release is a mistake (in project management). It will just cause some people to (rightfully) not update to security-fixes anymore, therefore making users less secure. That's esp. true for cautious users, ironically. That includes big companies.
(Sorry, that discussion doesn't really belong here, but it was used as argument to WONTFIX this bug. If there's a more appropriate point to discuss, let us know where.)
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.
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.
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.
And by ever, of course, I mean never.
Agreed.
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.
(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. ;)
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
No longer blocks: 588909
Reopening, we've switched to rapid releases and aren't shipping new features in minor releases anymore.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
No longer blocks: 586165
Blocks: 728797
No longer depends on: 572661
Summary: Don't expose the Gecko patch level in the UA string, only show the major version → Don't expose the Gecko patch level (13.X.Y) in the UA string, only show the major version (13.X)
Blocks: 728831
Attached patch patchSplinter Review
- made it so that pre-release indicators are actually removed
- updated files js/src/config

this fixes bug 728797 and thereby bug 728610
Assignee: dwitte → dao
Attachment #467621 - Attachment is obsolete: true
Status: REOPENED → ASSIGNED
Attachment #598827 - Flags: superreview?(gerv)
Attachment #598827 - Flags: review?(khuey)
Attachment #598827 - Flags: review?(bzbarsky)
Comment on attachment 598827 [details] [diff] [review]
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
Attachment #598827 - Flags: superreview?(gerv) → superreview+
Comment on attachment 598827 [details] [diff] [review]
patch

r=me on the HTTP bit
Attachment #598827 - Flags: review?(bzbarsky) → review+
Comment on attachment 598827 [details] [diff] [review]
patch

Review of attachment 598827 [details] [diff] [review]:
-----------------------------------------------------------------

::: 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.
Attachment #598827 - Flags: review?(khuey) → review+
Attached patch patch v2Splinter Review
addressed glandium's comments
http://hg.mozilla.org/mozilla-central/rev/0a7410527788
Status: ASSIGNED → RESOLVED
Closed: 14 years ago12 years ago
Keywords: dev-doc-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla13
Blocks: 728888
Blocks: 728894
Depends on: 728932
Blocks: 728952
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. :)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
http://hg.mozilla.org/mozilla-central/rev/be559203ece8

This was backed out for convenience, it doesn't depend on bug 588909.
Status: REOPENED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → FIXED
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?  ;-)
Bug 588909 surely accelerated this, although bug 728610 was an issue for Fennec before that.
... 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).
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.
(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.
> (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
(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...
(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.
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.
I wasn't talking about technical dependency in the sense of one bitrotting the other, but let's stop mincing words...
Here's a slightly cut down version of patch that only affects the Android-specific Gecko token in order to fix zimbra.
Attachment #599958 - Flags: approval-mozilla-beta?
Attachment #599958 - Flags: approval-mozilla-aurora?
Comment on attachment 599958 [details] [diff] [review]
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.
Attachment #599958 - Flags: approval-mozilla-beta?
Attachment #599958 - Flags: approval-mozilla-beta+
Attachment #599958 - Flags: approval-mozilla-aurora?
Attachment #599958 - Flags: approval-mozilla-aurora+
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?
(In reply to Vic from comment #112)
> Notice it is showing a1.

bug 728831

> Its also showing the date of build?

bug 588909
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.
Keywords: verifyme
Whiteboard: [parity-IE] → [parity-IE][qa+]
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.
(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.
(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.
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
Whiteboard: [parity-IE][qa+] → [parity-IE][qa!]
Docs updated:

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

Mentioned on Firefox 13 for developers.
No longer depends on: 751486
(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.
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
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.