+++ 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.
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
Can we wait for the smoke to clear a bit before making further changes in this area? Gerv
Comment on attachment 599328 [details] [diff] [review] possible patch Logical step after bug 572659, but ok.
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.
Nope, it wouldn't.
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.
(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.
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".
(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.
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
(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 on attachment 599328 [details] [diff] [review] possible patch please see comment 1
I keeping pinging Brendan about making an ownership decision but have not yet heard back :-| Gerv
updated to tip
Comment on attachment 620407 [details] [diff] [review] patch r=me
Attachment #620407 - Flags: review?(bzbarsky) → review+
Gavin, ping? Do you have concerns about this patch?
Attachment #620407 - Flags: superreview?(gavin.sharp) → superreview+
Target Milestone: --- → Firefox 16
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
(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
(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?
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
+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.
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.
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.
3 years ago
See Also: → bug 583181
You need to log in before you can comment on or make changes to this bug.