816749 - Port UA changes from bug 591537/bug 815743 to comm-central

Status: RESOLVED FIXED

(MailNews Core :: Build Config, defect)

Description

[Ian Neal]

Attachment: Add MOZ_UA_BUILDID [Checked in: comm-aurora, comm-beta, comm-release Comment 4]

Bug 815743 changed the way the UA is displayed and these should be ported to SM (and potentially TB).
MOZ_UA_BUILDID is added to the configure.sh /confvars.sh file.

Comment 1

[Justin Wood (:Callek)]

Comment on attachment 686826 [details] [diff] [review]
Add MOZ_UA_BUILDID [Checked in: comm-aurora, comm-beta, comm-release Comment 4]

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

r+ for a mail/ patch adding the same var to confvars.sh

Comment 2

[Justin Wood (:Callek)]

Comment on attachment 686826 [details] [diff] [review]
Add MOZ_UA_BUILDID [Checked in: comm-aurora, comm-beta, comm-release Comment 4]

a+ for branch landings (incl -release) minus mail/.

Comment 3

[Ian Neal]

Attachment: Add MOZ_UA_BUILDID for mail too [Checked in: Comment 3]

http://hg.mozilla.org/comm-central/rev/bd10532fbeae

Comment 4

[Ian Neal]

Comment on attachment 686826 [details] [diff] [review]
Add MOZ_UA_BUILDID [Checked in: comm-aurora, comm-beta, comm-release Comment 4]

http://hg.mozilla.org/releases/comm-aurora/rev/9fdd673177c6
http://hg.mozilla.org/releases/comm-beta/rev/7b0ff9c645ed
http://hg.mozilla.org/releases/comm-release/rev/6b04a598c2b7

Comment 5

[rsx11m]

(In reply to Ian Neal from comment #0)
> Bug 815743 changed the way the UA is displayed and these should be ported to
> SM (and potentially TB).

FTR: Firefox froze the build date unilaterally for their application and not for Gecko as such. Thus, this bug effectively ports bug 591537 to SeaMonkey and Thunderbird (and I'm kind of missing the discussion where it was decided whether or not to follow that example).

Comment 6

[Robert Kaiser]

rsx11m: That was done to reduce fingerprintability of the UA. It's pretty easy to track people on the server side by a fingerprint of HTTP header data such as that.

Comment 7

[rsx11m]

Yeah, I'm aware of these arguments which may apply to Firefox and other browsers with a high market share. For SeaMonkey the fact that you're using SeaMonkey alone makes you highly fingerprintable, thus any additional impact of the build ID and other items is comparably neglectable and the value of this measure questionable.

Comment 8

[rsx11m]

To clarify: The concern here is that a change was made in the heat of an oilspill release which may be appropriate for Firefox but not necessarily for SeaMonkey or Thunderbird with their individual needs and different circumstances. If the change was indeed intentional, I would have expected a proper discussion in the community rather than pushing it into a release with a 30-minute patch.

Comment 9

[Justin Wood (:Callek)]

(In reply to rsx11m from comment #8)
> To clarify: The concern here is that a change was made in the heat of an
> oilspill release which may be appropriate for Firefox but not necessarily
> for SeaMonkey or Thunderbird with their individual needs and different
> circumstances. If the change was indeed intentional, I would have expected a
> proper discussion in the community rather than pushing it into a release
> with a 30-minute patch.

I find the lack of this in the past a severe bug in itself (I had been under the impression it was in everywhere at the time). And a critical enough Privacy Fix. Thunderbird however is not doing the oilspill. And this is not a security-related oilspill.

Feel free to raise on our newsgroups, but I do not find it likely that we would make a change to this, especially since us differing in the text we have in the UA can be a cause of web-compat issues, when we differ from Firefox significantly.

Comment 10

[rsx11m]

There have been respective discussion threads in MozillaZine in both SeaMonkey and Thunderbird forums, where the build date in the UA is mostly used for support purposes to identify the build used (that's a lesser argument with the new rapid release system, obviously, but of interest for example in the nightly builds).

Not differing too much from Firefox for compatibility reasons is certainly an argument, but I still don't see the privacy or security implications of that move specifically in the scope of either SeaMonkey or Thunderbird which so far didn't apply the build-date freeze.

Comment 11

[Justin Wood (:Callek)]

(In reply to rsx11m from comment #10)
> Not differing too much from Firefox for compatibility reasons is certainly
> an argument, but I still don't see the privacy or security implications of
> that move specifically in the scope of either SeaMonkey or Thunderbird which
> so far didn't apply the build-date freeze.

For what its worth, prior to the (now backed out) patch, yes we had a flexible (changing) build ID, the one that Firefox is backing out in this chemspill changed us to have a *static* listing in the UA as well (the gecko ver). So we're not really losing anything with this vs with 2.14.0 [aiui] and still I will emphasize this discussion belongs on Newsgroups/our list.

I don't forsee my own opinion being changed, but I'm happy to read/hear counter arguments.

Comment 12

[Phoenix]

Ok, let's try to determine, is really inserting some dumb necrodate help to reduce user fingerprinting, or, as it was with original bug, this is completely imaginary thing and had nothing to do with real world.
Let's suppose that I'm some malicious site author and I want to "recognize" users. I'm taking user agent string and start looking, what info it can give me. Example:
Mozilla/5.0 (Windows NT 5.1; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16a2
What we can get from here on first look? Person is running Windows XP 32 bit and using Aurora version of browser (no, not because of a2 in string, which fingerprinting advocates also may want to remove, but because Gecko engine - rv:19.0 now in Aurora stage). And second narrow us down to just near 100 users. What next steps? Look at installed add-ons and exposed to web preferences, and with 99.5% probability you catch exact user.
Does real date adds anything to me? No, because it's *unreliable*, for fingerprinting user with it I need to predict user behavior - does he updates daily, or on work days or irregularly? User, visited today, with today date in UA, is he same, as yesterday one, who update, or new one? Date doesn't reveal this at all.
Does something change, if we turn to releases? No, all releases have same date and we again can't get any additional info from that date. One can argue, that date can allow distinguish release user from for-some-reasons-stay-on-beta/aurora/nightly user, but can we uniquely identify him if he visit again? Again no, as we can't predict his behavior.
So, summarizing all things, is there any real reasons for removing real date from user agent string? Argue, if you think so, with real world examples.

Comment 13

[Robert Kaiser]

(In reply to Phoenix from comment #12)
> Mozilla/5.0 (Windows NT 5.1; rv:19.0) Gecko/20100101 Firefox/19.0
> SeaMonkey/2.16a2

The a2 in there is another bug, as you also point out.

Comment 14

[Phoenix]

(In reply to Robert Kaiser (:[e-mail]) from comment #13)
> The a2 in there is another bug
And another dumb 'copy Firefox' decision, right

Comment 15

[rsx11m]

(In reply to Justin Wood (:Callek) from comment #11)
> I don't forsee my own opinion being changed, but I'm happy to read/hear
> counter arguments.

This has basically been discussed in the related bugs prior to Firefox 4.0 (bug 572661 and bug 588909), though relative to Firefox 3.x (SeaMonkey 2.0) at that time. To summarize, significant use cases for the date in the UA are identification of the builds for support purposes (e.g., phpBB lists the UA for individual posts); and, in heterogeneous enterprise/organization environments, to control/verify browser versions used for accessing or leaving the local network by the local users (e.g., handled at its firewall).

(In reply to Phoenix from comment #12)
> Ok, let's try to determine, is really inserting some dumb necrodate help to
> reduce user fingerprinting, or, as it was with original bug, this is
> completely imaginary thing and had nothing to do with real world.

It may reduce fingerprinting by a fraction for "accidental" fingerprinting, but the original study referred to in bug 572661 was based on the earlier branches and may be obsoleted by the rapid-release scheme implemented since Gecko 5.0. Thus, to be still valid, it would have to be repeated taking into account the different release conditions for SM 2.1-2.13.2, and also need to reflect in this case the comparably low percentage of browsers like SeaMonkey vs. the mainstream browsers in the overall "market" observed. Then, you'd have to determine the delta in that fingerprinting score between actual vs. frozen date and put it into relation to the overall fingerprintability of SeaMonkey vs. the other browsers, to determine whether or not it actually contributes to a significant amount or just disappears in what's to be considered noise.

On a side note, use of the build date for /intentional/ fingerprinting remains unaffected as long as navigator.buildID is available to a site without prior user consent (bug 583181), thus in terms of perceived vs. actual privacy or security, nothing is effectively gained other than making it a bit more difficult to get the date.

Comment 16

[rsx11m]

Second reply re procedural objections.

(In reply to Justin Wood (:Callek) from comment #11)
> For what its worth, prior to the (now backed out) patch, yes we had a
> flexible (changing) build ID, the one that Firefox is backing out in this
> chemspill changed us to have a *static* listing in the UA as well

Only bug 588909 was backed out, which is a change from date to version for the "Gecko/" UA token. Freezing the date is independent and should have been handled in a separate bug for each applications. While you are correct that the result of the change here doesn't win or loose anything relative to 2.14 (but relative to the state in 2.13.2 which has to be used here as the reference), it is a change in SeaMonkey itself independent of the Gecko bug to remove the date per se.

I'm thus disappointed that this change was simply pushed with a minor update, and on all channels at once. The correct procedure should have been to open a new bug specific to porting bug 591537 from Firefox to SeaMonkey, discuss pros and cons there, and if so decided, to let the patch ride the train from comm-central to comm-release as it is commonly done for non-security/stability changes.

Comment 17

[Robert Kaiser]

(In reply to rsx11m from comment #15)
> On a side note, use of the build date for /intentional/ fingerprinting
> remains unaffected as long as navigator.buildID is available to a site
> without prior user consent (bug 583181)

Don't confuse server-side vs. client-side fingerprinting. People concerned about client-side fingerprinting, which from what I heard is used way more rarely than server-side, can use NoScript or disable JavaScript. They cannot do anything against server-side fingerprinting, which uses the UA string as a major ingredient.

Comment 18

[rsx11m]

Yes, but then you'll have to disable JavaScript for that entire site, which may not be feasible if you want it to run properly either... and then the question is to which extent the use of the NoScript add-on contributes to the fingerprinting, which quite likely has a larger score than just the build date.  ;-)