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

RESOLVED FIXED in Firefox 16

Status

()

Firefox
General
RESOLVED FIXED
6 years ago
2 years ago

People

(Reporter: dao, Assigned: dao)

Tracking

(Blocks: 1 bug, {privacy, relnote})

Trunk
Firefox 16
privacy, relnote
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [parity-IE], URL)

Attachments

(1 attachment, 1 obsolete attachment)

(Assignee)

Description

6 years ago
+++ 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.
(Assignee)

Updated

6 years ago
Whiteboard: [parity-IE]
(Assignee)

Comment 1

6 years ago
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.
Assignee: nobody → dao
Status: NEW → ASSIGNED
(Assignee)

Updated

6 years ago
Attachment #599328 - Flags: superreview?(gavin.sharp)
Attachment #599328 - Flags: review?(bzbarsky)
Can we wait for the smoke to clear a bit before making further changes in this area?

Gerv
(Assignee)

Comment 3

6 years ago
Comment on attachment 599328 [details] [diff] [review]
possible patch

Logical step after bug 572659, but ok.
Attachment #599328 - Flags: superreview?(gavin.sharp)
Attachment #599328 - Flags: review?(bzbarsky)

Comment 4

6 years ago
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

6 years ago
Nope, it wouldn't.

Comment 6

6 years ago
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.
(Assignee)

Comment 7

6 years ago
(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

6 years ago
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."
Because this patch hasn't landed yet.


I have a question, why we leave a "13.0" instead "13".
(Assignee)

Comment 10

6 years ago
(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.
(Assignee)

Updated

6 years ago
Blocks: 728888
(Assignee)

Comment 11

6 years ago
Gerv, can we proceed with this?
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
(Assignee)

Comment 13

5 years ago
(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.
(Assignee)

Comment 14

5 years ago
Comment on attachment 599328 [details] [diff] [review]
possible patch

please see comment 1
Attachment #599328 - Flags: superreview?(gavin.sharp)
Attachment #599328 - Flags: review?(bzbarsky)
I keeping pinging Brendan about making an ownership decision but have not yet heard back :-|

Gerv
(Assignee)

Comment 16

5 years ago
Created attachment 620407 [details] [diff] [review]
patch

updated to tip
Attachment #599328 - Attachment is obsolete: true
Attachment #620407 - Flags: superreview?(gavin.sharp)
Attachment #620407 - Flags: review?(bzbarsky)
Attachment #599328 - Flags: superreview?(gavin.sharp)
Attachment #599328 - Flags: review?(bzbarsky)
Comment on attachment 620407 [details] [diff] [review]
patch

r=me
Attachment #620407 - Flags: review?(bzbarsky) → review+

Updated

5 years ago
Target Milestone: --- → Firefox 17
Target Milestone: Firefox 17 → ---
(Assignee)

Updated

5 years ago
Blocks: 728894
(Assignee)

Comment 18

5 years ago
Gavin, ping? Do you have concerns about this patch?
Attachment #620407 - Flags: superreview?(gavin.sharp) → superreview+
(Assignee)

Comment 19

5 years ago
http://hg.mozilla.org/integration/mozilla-inbound/rev/a240fd5029da
Target Milestone: --- → Firefox 16
https://hg.mozilla.org/mozilla-central/rev/a240fd5029da
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED

Comment 21

5 years ago
(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
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

5 years ago
(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 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?
Depends on: 770244
Keywords: relnote
Duplicate of this bug: 771388

Comment 26

5 years ago
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?
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

5 years ago
+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

5 years ago
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.

Updated

5 years ago
Blocks: 812263

Comment 30

5 years ago
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.
Restrict Comments: true

Updated

2 years ago
See Also: → bug 583181
You need to log in before you can comment on or make changes to this bug.