+++ This bug was initially created as a clone of Bug #728831 +++ 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.

Gecko 13.0 corresponds to SeaMonkey 2.10 by current counting. As a counter-argument, the main motivation for support reasons is to verify that a user is current with his or her installation simply based on the user-agent string. With the rapid-release system, this is less of an issue these days, though thus far all but about two releases had "dot" follow-ups. With both the build date and the patch level gone from the Gecko portions of the UA string, the full SeaMonkey version remains the only indicator if the user is up to date. Assuming that this is a decision each application has to get to individually (though at least the Firefox compatibility token should probably match whatever Firefox does), the question is if it's the right thing to do for SeaMonkey as well or not. The supposed benefits are highly overrated IMO, and the main reason for introducing this in an ad-hoc manner was that the UA string as redesigned in bug 588909 broke the Zimbra web-mail also used by Mozilla itself, thus the motivation was rather weak to pick this issue up at this specific time.

(In reply to rsx11m from comment #1) > Gecko 13.0 corresponds to SeaMonkey 2.10 by current counting. Er, sure, sorry. For the rest, exposing the security patch level is not just a fingerprinting issue, it can even be possibly used as an attack vector (hah, this user is vulnerable to my exploit, yippie!) and SeaMonkey should keep in line with what the other Mozilla browser applications are doing - bugs like this are filed for Firefox, Fennec, and B2G at least, see dependencies in bug 572659. Exposing things for support purposes should happen via about:support or specialized interfaces (I think we should start exposing some things like this via a navigator.* interface that would only be accessible when granted by the user or on an in-browser whitelist, similar to add-on installations or geolocation (though the latter doesn't have a whitelist - in this case, sites like SUMO or something similar for SeaMonkey could get whitelisted by default).

(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #2) > For the rest, exposing the security patch level is not just a fingerprinting > issue, it can even be possibly used as an attack vector (hah, this user is > vulnerable to my exploit, yippie!) and SeaMonkey should keep in line with > what the other Mozilla browser applications are doing - bugs like this are > filed for Firefox, Fennec, and B2G at least, see dependencies in bug 572659. Well, there is a change of the major Gecko version every six weeks, so that argument which was still valid when there were "real" branches does no longer hold (admittedly, in either direction). From the support point of view, oilspill releases occur a week or two after the main release and usually address really urgent issues, thus it's important to verify if they were applied or not. The other case were "dot" releases matter is with Extended Support Releases, without the minor number it's impossible to tell if a user runs an non-updated 10.0-based regular release or is current with a 10.0.7 ESR build. That may be mitigated by displaying the full version number in the "About" window but prevents automation, in which case some whitelist JavaScript-accessible feature would be needed but adds further complexity, etc. As for "SeaMonkey should keep in line with what Firefox decides to do", keep in mind that neither SeaMonkey nor Thunderbird followed the example of Firefox freezing the build date to a meaningless constant (including beta and release builds), so that paradigm was violated on purpose already before.

This is on hold for now after both bug 588909 and the change in its wake prompting bug 572659 (which relates to the change proposed here) have been backed out subject to further investigation on the breakages seen so far. See bug 588909 comment #84 for further details, and that would also be the bug where related discussions should be expected.

(In reply to rsx11m from comment #3) > From the support point of > view ... the UA is a bad source of information. As mentioned, we should create other sources for support, but not something like the UA that is sent which every single HTTP request. > thus it's important to verify if they > were applied or not. Not for common websites. > The other case were "dot" releases matter is with Extended Support Releases Not for common websites and not for SeaMonkey, which doesn't have ESR anyhow. (In reply to rsx11m from comment #4) > This is on hold for now after [...] have been backed out Sure.

(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #5) > ... the UA is a bad source of information. As mentioned, we should create > other sources for support, but not something like the UA that is sent which > every single HTTP request. That's all you usually get, e.g., in support forums. Take mozillaZine as example. > Not for common websites and not for SeaMonkey, which doesn't have ESR anyhow. Not yet, but intended and rather likely as long as resources are available. (In reply to Robert Kaiser (:kairo@mozilla.com) from comment #2) > fingerprinting issue, it can even be possibly used as an attack vector That was suggested in the bug 572659 already as well. As for the fingerprinting argument, using SeaMonkey on its own leaves likely a much better fingerprint than Firefox as it has a devoted but much smaller use base. And, Google will certainly keep track of your browsing habits without having to rely on the UA string. ;-) As for attack vector, you are assuming in this argument that a malicious site first tries to figure out the patch level before attempting a version-specific exploit rather than simply trying it and see if it proceeds. But again, this all has been discussed elsewhere before...

I think this can be marked as duplicate of Bug 1333933

I think there is a slight difference between Bug 1333933 and this, that it requires a user to turn on 'privacy.resistFingerprinting' in Bug 1333933. But this bug is talking about spoof UA by default. So, we could either marked this as duplicate of Bug 1333933 and leave a comment here to inform that you have to turn on 'privacy.resistFingerprinting' or leave this bug still open. Personally, I don't know which on is better.

That's true. So, we shouldn't leave a bug open indefinitely if we don't intend to do it. So I'm fine leaving this open to track the "Do it by default" action, but only if leaving it open implies we haven't made a decision about whether we will do it or we WONTFIX. I'm guessing we won't/can't make that decision until we know breakage information though.

I would probably go with a WONTFIX for this bug in favor for the spoof pref implemented in Bug 1333933, then have another bug to expose that pref in SeaMonkey's Security pane, thus leaving it up to the user whether or not to "hide" its true browser identity (and that may actually be a "fix" for sites that don't recognize SeaMonkey correctly with UA sniffing). Due to the relatively low market share, SeaMonkey will /always/ be at higher risk of finger printing, thus a generic "switch" to spoof the entire UA string and not just reducing the printability of individual UA components. The default of 'privacy.resistFingerprinting' for SeaMonkey should be false, which we currently don't provide (I'll open a bug for that).

I believe we completed this in Bug 583181 - if I'm incorrect about that; please re-open.