Last Comment Bug 728831 - Don't expose the Firefox patch level (13.X.Y) in the UA string, only show the major version (13.X)
: Don't expose the Firefox patch level (13.X.Y) in the UA string, only show the...
Status: RESOLVED FIXED
[parity-IE]
: privacy, relnote
Product: Firefox
Classification: Client Software
Component: General (show other bugs)
: Trunk
: All All
: -- normal with 4 votes (vote)
: Firefox 16
Assigned To: Dão Gottwald [:dao]
:
:
Mentors:
http://www.delorie.com:81/some/url.txt
Depends on: 572659 770244
Blocks: http-fingerprint 584683 728888 728894 812263
  Show dependency treegraph
 
Reported: 2012-02-20 03:30 PST by Dão Gottwald [:dao]
Modified: 2015-11-21 03:37 PST (History)
54 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
possible patch (4.04 KB, patch)
2012-02-21 13:25 PST, Dão Gottwald [:dao]
no flags Details | Diff | Splinter Review
patch (3.94 KB, patch)
2012-05-02 11:46 PDT, Dão Gottwald [:dao]
bzbarsky: review+
gavin.sharp: superreview+
Details | Diff | Splinter Review

Description Dão Gottwald [:dao] 2012-02-20 03:30:27 PST
+++ This bug was initially created as a clone of Bug #572659 +++

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.
Comment 1 Dão Gottwald [:dao] 2012-02-21 13:25:16 PST
Created attachment 599328 [details] [diff] [review]
possible patch

This patch can be used if we want to commit to Firefox using the same version as Gecko. Otherwise the version needs to set be or constructed separately.
Comment 2 Gervase Markham [:gerv] 2012-02-22 05:01:57 PST
Can we wait for the smoke to clear a bit before making further changes in this area?

Gerv
Comment 3 Dão Gottwald [:dao] 2012-02-22 05:12:51 PST
Comment on attachment 599328 [details] [diff] [review]
possible patch

Logical step after bug 572659, but ok.
Comment 4 rsx11m 2012-02-22 08:26:13 PST
It all depends on bug 588909; if it doesn't make it and Fennec reverts that part of their change per bug 729348, then the basis for bug 572659 (and hence this one) would be gone as well.
Comment 5 Ben Bucksch (:BenB) 2012-02-22 08:50:25 PST
Nope, it wouldn't.
Comment 6 rsx11m 2012-02-22 09:30:16 PST
Based on the history of bug 572659 resulting from bug 671634 and bug 588909 it sure does, but I realize that some people apparently don't *want* to look at it in this way.  ;-)

Anyway, shutting up now.
Comment 7 Dão Gottwald [:dao] 2012-02-22 11:32:15 PST
(In reply to rsx11m from comment #6)
> Based on the history of bug 572659 resulting from bug 671634 and bug 588909
> it sure does, but I realize that some people apparently don't *want* to look
> at it in this way.  ;-)

Bug 572659 was filed before bug 588909. The latter can't be the basis for the former. I reopened it saying "we've switched to rapid releases and aren't shipping new features in minor releases anymore" -- again logically independent from bug 588909. Bug 588909 (via bug 728797) is an /additional/ motivation for this.

> Anyway, shutting up now.

Ok, thanks.
Comment 8 Vic 2012-02-26 20:11:46 PST
Below was supposed to be posted here, instead of Bug 572659, which was listed as Fixed, Comment 112:

"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."
Comment 9 Virtual_ManPL [:Virtual] - (ni? me) 2012-02-27 06:48:13 PST
Because this patch hasn't landed yet.


I have a question, why we leave a "13.0" instead "13".
Comment 10 Dão Gottwald [:dao] 2012-02-27 07:10:49 PST
(In reply to Virtual_ManPL from comment #9)
> I have a question, why we leave a "13.0" instead "13".

It's expected that the latter would break UA string sniffers. Feel free to file a separate bug on this, though, to investigate the exact impact.
Comment 11 Dão Gottwald [:dao] 2012-03-25 13:01:16 PDT
Gerv, can we proceed with this?
Comment 12 Gervase Markham [:gerv] 2012-03-26 04:23:15 PDT
This bug makes us send "Firefox X.Y" all the time, when before we would send one of "Firefox X.Ya1", "Firefox X.Ya2", "Firefox X.Y" or "Firefox X.Y.Z".

Because the new string is one of the possible set of previous strings, this change should not break any working parsing code. It just makes it more difficult to differentiate alpha, beta, release and point-release builds from one another. Comment #0 makes the case as to why that is a good thing - "test what you ship" and fingerprinting being 2 main reasons.

There is the question of whether there are sites which legitimately depend on making such distinctions. Some of that was tackled over in bug 572659. SUMO has about:support. Things like update pings and the first run page don't care about the version in the UA string.

Given that, I am generally in favour of it. However, the decision about a module owner for the UA string is still pending with the Module Owners group, and it seems unwise to make any changes before that is decided.

Gerv
Comment 13 Dão Gottwald [:dao] 2012-04-24 21:41:28 PDT
(In reply to Gervase Markham [:gerv] from comment #12)
> However, the decision about a
> module owner for the UA string is still pending with the Module Owners
> group, and it seems unwise to make any changes before that is decided.

Any update? It's been more than two months now and I don't think it makes sense to wait indefinitely with any HTTP header changes.
Comment 14 Dão Gottwald [:dao] 2012-04-26 07:13:22 PDT
Comment on attachment 599328 [details] [diff] [review]
possible patch

please see comment 1
Comment 15 Gervase Markham [:gerv] 2012-04-27 07:57:34 PDT
I keeping pinging Brendan about making an ownership decision but have not yet heard back :-|

Gerv
Comment 16 Dão Gottwald [:dao] 2012-05-02 11:46:35 PDT
Created attachment 620407 [details] [diff] [review]
patch

updated to tip
Comment 17 Boris Zbarsky [:bz] (still a bit busy) 2012-05-04 12:20:08 PDT
Comment on attachment 620407 [details] [diff] [review]
patch

r=me
Comment 18 Dão Gottwald [:dao] 2012-06-19 08:13:19 PDT
Gavin, ping? Do you have concerns about this patch?
Comment 20 Ryan VanderMeulen [:RyanVM] 2012-06-23 05:47:45 PDT
https://hg.mozilla.org/mozilla-central/rev/a240fd5029da
Comment 21 Robert Kaiser 2012-06-30 07:53:00 PDT
(In reply to Dão Gottwald [:dao] from comment #1)
> This patch can be used if we want to commit to Firefox using the same
> version as Gecko.

I wonder if we should write this down somewhere explicitely, as this is the first (and currently only) place in the code where we make the Firefox version explicitely the same as the Gecko version and be derived from milestone.txt instead of browser/config/version.txt
Comment 22 Gervase Markham [:gerv] 2012-07-04 07:23:03 PDT
KaiRo: can you file a follow-up bug about that with a concrete proposal?

It would be best to get the Firefox version from the file where you say the master number is, but perhaps that's too much work for small gain.

Gerv
Comment 23 Robert Kaiser 2012-07-04 15:20:12 PDT
(In reply to Gervase Markham [:gerv] from comment #22)
> KaiRo: can you file a follow-up bug about that with a concrete proposal?

My probably is that I have no clue which way we want to go there - either disentangle this case or make sure the Firefox version.txt is always derived from the toolkit milestone.txt - that's why I called for just documenting this case. I'm no decision maker and personally unsure as to what the best way is, so I have no idea where to file a bug and what to file it on, exactly.
It's just dangerous IMHO to make that assumption in this single place and not even have that documented very widely.
Comment 24 Anthony Ricaud (:rik) 2012-07-12 17:09:06 PDT
Comment 0 mentions some use-cases like AMO. We also use the patch level on mozilla.org to inform our users if they are up to date or not.

Is there any way to get this data?
Comment 25 raymond [:retornam] (needinfo? me) 2012-07-27 10:52:01 PDT
*** Bug 771388 has been marked as a duplicate of this bug. ***
Comment 26 Matthew Atkinson 2012-10-16 04:20:30 PDT
We've just upgraded about 70 of our users to 16.0 before the vulnerability was found. We've put out the 16.0.1 version, but wanted to ban 16.0 at the proxy to force people to upgrade, as the normal Firefox auto-upgrade is very slow. 

So, I banned User-Agents of 16.0 at the proxy, only to find that I'd banned everyone with 16.0.1 as well. The release notes are slightly incorrect, in that they refer to pre-release versions, and this is a released version, but I found this 'Bug', which is stopping me from blocking the insecure version. 

I can see why you've done this, but this side effect is not helpful. Is there any way I can get round it?
Comment 27 Gervase Markham [:gerv] 2012-10-17 02:28:50 PDT
Firefox 16.0 and 16.0.1 send the same headers by design, as you have seen in this bug. So there is no way of telling the different between them by looking at HTTP traffic (and if there was, it would be a privacy/fingerprinting bug we'd want to fix).

We apologise for the inconvenience caused to you by our oversight in releasing Firefox with a security problem. I suggest the best method to fix it is to email your users and require them to trigger the upgrade mechanism.

If you're not aware of the Enterprise Working Group <https://wiki.mozilla.org/Enterprise>, that may be something you want to get involved with, as they may well have enterprise-y deployment tools you could use to avoid this sort of issue in future, and also provide more timely updates if you wanted them.

Gerv
Comment 28 Jeff G 2012-10-29 10:09:30 PDT
+1 on Matthew's comments. We too use the user agent string to enforce current version usage within our corporate environment and this change makes that impossible without doing some sort of client-side testing.
Comment 29 Matthew Atkinson 2012-11-06 02:19:02 PST
I've created a new Bug https://bugzilla.mozilla.org/show_bug.cgi?id=808979 to allow reversion of this change for people like us for whom it has become a security problem.
Comment 30 Yunier J. 2012-12-02 06:29:40 PST
How I get the right version now? I developed a plugin for WordPress for alert to users that are using a old version but now not know how made this because for example: 

Last version is: 16.0.2
UserAgent said: 16.0

and I need compare both versions.

Note You need to log in before you can comment on or make changes to this bug.