591537 - Freeze UA build id for Firefox branded builds

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect)

Description

[[e-mail]]

We're not dropping build ID for 4, but we can freeze it.

We should pick an arbitrary value to freeze it to -- something recognizable, like 20100101 -- or even something nonsensical, like 20100000? -- so that people don't think it's legit. (For instance, in Bugzilla.)

I'm kinda in favor of 20100000. Thoughts?

Comment 1

[[e-mail]]

Attachment: patch

This sets it to 20100101 for Firefox branded builds, and leaves it unfrozen for Minefield. I think that's maximally compatible and won't step on anyone's toes.

Comment 2

[Dave Garrett]

If the build ID is going to stay in the UA, I really think it should stay meaningful. I don't think freezing it to nonsense will help anything much in the bad UA sniffing department.

If this were to be done, simply "Gecko/2010" would at least make some sense.

Comment 3

[Boris Zbarsky [:bzbarsky]]

> help anything much in the bad UA sniffing department.

It sure would; it'd prevent that rash of sites breaking on the first update we ship in a new year.  It happens every single year (with sites like yahoo.com, etc).  And years of evangelism haven't necessarily helped; it took 5 years of sending them mail to get fly.faa.gov to stop doing the stuff you see in bug 330418.

> If this were to be done, simply "Gecko/2010" would at least make some sense.

Unfortunately, some people assume an 8-digit id.  When we changed it to 10 digits once (added the hour), sites broke; feel free to look up the bugs on this.  So switching to "2010" is no better than removing it altogether.

Comment 4

[Dave Garrett]

What if a site is checking for a "current" build, i.e. expects the current year? Then it'll break in 2011. There's all sorts of routes to stupidity here. :/

Honestly, I would still expect the shenanigans to persist if they're doing dumb stuff like this. Removing it entirely might be nice, but as already discussed, that's not happening.

> > If this were to be done, simply "Gecko/2010" would at least make some sense.
> 
> Unfortunately, some people assume an 8-digit id.

Are there enough to care? No matter what is changed, it'll break _something_. The number of tokens has changed and the lengths of UAs are all going to be different. We should try to minimize the long term problems but even removing the "U;" broke things so at some point we have to just let a few things break. There is enough flux for Firefox 4 that some TE bugs will be required in any instance.

The bug 330418 example was searching for a specific build string. "Gecko/2010" would fit into that concept still and isn't nonsense.

Comment 5

[Boris Zbarsky [:bzbarsky]]

> What if a site is checking for a "current" build, i.e. expects the current
> year? 

We have yet to encounter one of those....

> Honestly, I would still expect the shenanigans to persist 

How so?  They're not being malicious, just insufficiently clueful.  All we're doing is removing the footgun.

> Are there enough to care? 

There were last time we ran into the problem.

Comment 6

[Dave Garrett]

> insufficiently clueful.

I like that description.

Any UA string surface given poses a risk of dumb usage, including a frozen date. It might be true that the risk is lowered as we hope, but I'm just saying that we shouldn't have to have more nonsense in the UA than we already have.

> All we're doing is removing the footgun.

It's not being removed; it's being changed to something hopefully less bad. I have the nagging feeling that some idiot will come up with a new and interesting way to abuse anything here. ;)

Comment 7

[Dão Gottwald [:dao]]

Comment on attachment 470116 [details] [diff] [review]
patch

> MOZ_APP_NAME	= @MOZ_APP_NAME@
> MOZ_APP_DISPLAYNAME = @MOZ_APP_DISPLAYNAME@
> MOZ_APP_UA_NAME = @MOZ_APP_UA_NAME@
> MOZ_APP_VERSION = @MOZ_APP_VERSION@
>+MOZ_APP_UA_BUILDID = @MOZ_APP_UA_BUILDID@

I'm not sure about MOZ_APP_UA. I'm using MOZ_UA in bug 591387 as it's not app specific.

Otherwise this looks fine to me, but ideally a build config peer would review it. Maybe also get it superreviewed since it's apparently possible to disagree with this change (see Dave Garrett), although it seems like a no-brainer to me.

Comment 8

[[e-mail]]

Comment on attachment 470116 [details] [diff] [review]
patch

Cool. Changed to MOZ_UA_BUILDID locally.

khuey, jst, how does this look?

Comment 9

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Comment on attachment 470116 [details] [diff] [review]
patch

>diff --git a/js/src/configure.in b/js/src/configure.in
>+AC_SUBST(MOZ_APP_UA_BUILDID)

Lose this.  There's no need for any of this stuff to be in js/src's configure.in.

r=me.

Comment 10

[Dão Gottwald [:dao]]

(In reply to comment #9)
> Comment on attachment 470116 [details] [diff] [review]
> patch
> 
> >diff --git a/js/src/configure.in b/js/src/configure.in
> >+AC_SUBST(MOZ_APP_UA_BUILDID)
> 
> Lose this.  There's no need for any of this stuff to be in js/src's
> configure.in.

I'm confused, what did bug 581008 comment 33 refer to?

Comment 11

[Dave Garrett]

(In reply to comment #7)
> Maybe also get it superreviewed since it's apparently possible to disagree
> with this change (see Dave Garrett), although it seems like a no-brainer to me.

No-brainer in the short term to work around (not fix) a few dumb sites, though I would have preferred better options like ditching it entirely. For example:
Mozilla/5.0 (X11; Linux i686; Gecko/rv:2.0.x) Firefox/4.0.x

However this change means for the rest of eternity we'll be saying Firefox was built on Jan 1st 2010, or at least Jan 1st of some year if we ever change the year on major releases, which we probably won't. Essentially we're adding another "Mozilla/5.0" style useless bit, though more cryptic this time. We should be reducing the junk in the UA, not increasing.

To be clear, I'm primarily saying this is stupid, which is something I think we can probably all agree on to some degree. The "necessary stupidity" argument may win the day here, but I'd just rather we not appease all bad sniffing sites with this one and drop to just Gecko/2010 or Gecko/2. Simple==better.

Comment 12

[Dave Garrett]

Clarifying title based on comment 1. This affects releases and not Minefield.

Comment 13

[[e-mail]]

http://hg.mozilla.org/mozilla-central/rev/7652c4f2d60d

Comment 14

[Wolfgang Rosenauer [:wolfiR]]

Hmm, I noticed that only now after landing.
If the buildid is now fixed there is currently no way left to differentiate between MoCo and Linux distribution builds in crash-stats.m.c.

Comment 15

[[e-mail]]

Does crashstats get its data from the UA or nsIXULAppInfo.platformBuildID?

Comment 16

[[e-mail]]

Answering my own question, it's the latter since it has >8 digits: e.g. 20100316055951

So it's unaffected by this change.

Comment 17

[Wolfgang Rosenauer [:wolfiR]]

http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsAppRunner.cpp#2951

Ah, this is only about the UA string.
It gets confusing somehow to have the same thing with different meaning now.

Comment 19

[Masatoshi Kimura [:emk]]

This should be documented in <https://developer.mozilla.org/En/Firefox_User_Agent_String_Reference>.

Comment 20

[Daniel Veditz [:dveditz]]

This is insanely stupid, we should be removing this cruft. If sites break on a hundred million users they'll have a motivation to fix it long before the less adventurous users migrate to Firefox 4. Meanwhile users who must use those broken sites and don't know about (or can't be bothered with) the User Agent Switcher can stick with the still-supported Firefox 3.6.x

We're being far too conservative with our UA changes, a major version like Gecko 2 is precisely when we should be bold.

Comment 21

[Dave Garrett]

Thank you Daniel! It's nice to have someone other than just me arguing against adding more intentionally bogus data to the UA string. :)

Comment 22

[[e-mail]]

I'd take this up with shaver. He didn't want to take dropping of the build ID for 4.

Comment 23

[u88484]

(In reply to comment #21)
> Thank you Daniel! It's nice to have someone other than just me arguing against
> adding more intentionally bogus data to the UA string. :)

I'm also against it but I don't have any say and bugzilla isn't normally used to advocate for/against something and no one has created a specific newsgroup thread about this.

Comment 24

[Dave Garrett]

(In reply to comment #23)
> bugzilla isn't normally used to advocate for/against something

No, but it is used to discuss/debate things all the time. (advocate != debate)

(In reply to comment #22)
> I'd take this up with shaver. He didn't want to take dropping of the build ID
> for 4.

As I said above, there are alternatives to dropping it outright such as changing releases to use just Gecko/2010 or just simply Gecko/2.

Comment 25

[Dão Gottwald [:dao]]

Neither Gecko/2010 nor Gecko/2 would be ideal, pushing that wouldn't be worth it. The next best change would be Gecko/2.0 and getting rid of "rv:".

Comment 26

[Masatoshi Kimura [:emk]]

In all cases, it should be documented.
<https://developer.mozilla.org/En/Firefox_User_Agent_String_Reference>
> Gecko/build indicates that the browser is based on Gecko, and provides the
> build id (in yyyymmdd form) indicating the release date of the browser.
Clearly Firefox 4 was not released at 01 Jan. 2010.

Comment 27

[Dave Garrett]

(In reply to comment #25)
> Neither Gecko/2010 nor Gecko/2 would be ideal, pushing that wouldn't be worth
> it. The next best change would be Gecko/2.0 and getting rid of "rv:".

Right, and that was decided against too.

Ideal would be:
Gecko/2.0.x Firefox/4.0.x (platform)
(with an added build ID for nightlies only)

But after much discussion we somehow ended up with not that. We've got a series of less ideal methods and are now down to debating about what goes in a build ID slot we wanted to get rid of for releases in the first place. The current ruling is fixed semi-gibberish and I would rather a fixed year at far least.

Bottom line: Firefox now declares itself to always have been built on the first day of 2010. I say this is stupid, Daniel Veditz says it's "insanely stupid", some users find it confusing, and we'll be stuck with it "forever" at this rate just like "Mozilla/5.0".

The only thing this bug works around (not fixes) are very very very very dumb UA sniffing scripts in poorly maintained sites. Yes, it sucks that they break, but not all of us really want to have to add more junk to the UA string to make a vain attempt at holding back the never ending flood of dumb UA sniffing problems. Fixing it would require getting rid of the build ID entirely for releases and this middle-ground solution is not good in my and others' opinions. Of course, the world won't end because the UA lost some IQ points, but it's still dumb. ;)

Most further discussion along this line, however, takes us out of the scope of this bug and back into the winding maze of other UA change bugs with various other resolutions...

Comment 28

[Dave Garrett]

To give another hypothetical result of freezing the build ID:

Say it's the year 201X and Firefox N has just be released. Yay, new features, new capabilities. Let's say some stupid site is still doing the bad sniffing we're trying to appease here, for example something like bug 330418 comment 1 (quoted previously above) whereby it just checks for whatever specific "Gecko/*" it says it "supports". Our now frozen Gecko/20100101 is what the stupid site will be checking for as its last entry. Now let's say Firefox N changed something this site relied on in Firefox N-1. This site will now break under Firefox N because Gecko/20100101 is what it's looking for. It won't see the browser as new because we intentionally lied to it. Yes, by now it would be really stupid to still be sniffing this frozen build ID, but then again, the reason we're considering freezing this build ID is because its sniffing was already stupid. Solution? Change the "frozen" build ID with each major version (and each minor-ish Lorentz-style update), but then it's not really frozen, now is it.

I may or may not be able to come up with more hypotheticals, but some hastily written UA sniffer script will probably find something new that we can't conceive of right now.

Freezing is not a magic bullet that will fix this problem and what it's frozen to is known to be bogus and is already confusing people.

A "Gecko/year" token with the year indicating the year of its major release makes some form of sense. It won't fall prey to the above hypothetical as it would be updated only on new major Gecko versions. Yeah, some site expecting 8 digits will choke, but I don't think we should care and no matter what we do *something* will choke because UA sniffing is in-general a bad idea that tends to break often.

(my apologies for the longwindedness of my argument here)

Comment 29

[Dave Garrett]

By the way, I mean no offense, but neutral procedural complaint: This bug was filed one hour after the bug to decide all Firefox 4.0 UA string changes was marked FIXED (bug 586165) and was filed outside of that dependency tree with previous discussions. As stated by Kurt above there was also no newsgroup discussion on the precise topic of freezing to 20100101.

Comment 30

[[e-mail]]

I agree completely, but there's not much I can do here short of backing this change out. We could, of course, do that. We should be open to discussion on whether this change, taken on its own, is worthwhile or not.

The debate on removing the build ID entirely is a righteous one, as are all the other discussions in the various bugs, and I hope we can revisit it in the near future.

Comment 31

[Dão Gottwald [:dao]]

(In reply to comment #27)
> we'll be stuck with it "forever" at this rate
> just like "Mozilla/5.0".

Freezing the date does not rule out removing it in a later step.

> The only thing this bug works around (not fixes) are very very very very dumb
> UA sniffing scripts in poorly maintained sites.

No, it also made Linux builds less distinguishable. Win for bug 572650.

> Yes, it sucks that they break,
> but not all of us really want to have to add more junk to the UA string to make
> a vain attempt at holding back the never ending flood of dumb UA sniffing
> problems.

Nothing has been added in this bug.

Comment 32

[Dave Garrett]

(In reply to comment #30)
> I agree completely, but there's not much I can do here short of backing this
> change out. We could, of course, do that. We should be open to discussion on
> whether this change, taken on its own, is worthwhile or not.
>
> The debate on removing the build ID entirely is a righteous one, as are all the
> other discussions in the various bugs, and I hope we can revisit it in the near
> future.

Thanks for your candor. Because this specific change went from filing to in beta 5 so quick, I think we're going to get more after-the-fact discussion than usual, though I don't think an immediate backout is warranted. There's also the oddity that this doesn't affect Minefield users so people are only going to see it in the betas and wonder why it's "broken". We've already got a dupe to here and beta 5 is not even officially out yet.

Removing it from releases is one of those things that's sorta agreed on, but we can't seem to find a consensus way to do it with agreed upon fallout. Hopefully we can come to a decent solution.

(In reply to comment #31)
> Freezing the date does not rule out removing it in a later step.

True, but it still means that Firefox 4.0.x will have this weird issue, unless the closed out bug for finalizing Firefox 4.0 UA stuff is not really supposed to be closed and labeled "done".

> > The only thing this bug works around (not fixes) are very very very very dumb
> > UA sniffing scripts in poorly maintained sites.
> 
> No, it also made Linux builds less distinguishable. Win for bug 572650.

Ok, not "only", thanks for the correction. This plus bug 591573 will help that problem. However, it can also be fixed by just giving Linux builds their mozilla.org build counterpart's IDs in the UAs. Standardizing this ID across the various Firefox branded builds, at least in the UA, to that of the base build makes sense and would be valid in that the date would be of the base from Mozilla. In other words, make it more of a base source ID than just a build date and making distro builds not unique in their UAs.

> > Yes, it sucks that they break,
> > but not all of us really want to have to add more junk to the UA string to make
> > a vain attempt at holding back the never ending flood of dumb UA sniffing
> > problems.
> 
> Nothing has been added in this bug.

That's a matter of perspective. We had Gecko/YYYYMMDD and were updating it but now we have Gecko/20100101 which is frozen. We had an actual value and now have just a number that only looks like a real value. Something real was removed and something intentionally fake was added in its place. The later 4 bytes in particular are especially "junky", as nothing having to do with January 1st is really involved here. That was added conceptually, in that we previously did not have this non-real data in the UA.

Comment 33

[Dão Gottwald [:dao]]

(In reply to comment #32)
> However, it can also be fixed by just giving Linux builds their
> mozilla.org build counterpart's IDs in the UAs. Standardizing this ID across
> the various Firefox branded builds, at least in the UA, to that of the base
> build makes sense and would be valid in that the date would be of the base from
> Mozilla.

We don't want to standardize it, see below.

> We had an actual value and now have
> just a number that only looks like a real value.

Exactly. It's the point of this bug. We don't want a meaningful date there. We'd remove the whole thing right now if there were no compatibility concerns.

Comment 34

[Dave Garrett]

(In reply to comment #33)
> We don't want to standardize it

I don't mean fully standardize it. I mean have the build ID which an official mozilla.org Linux build gets be used for all builds created by all Linux distros, even if they were actually physically built on a later date. Other OSes would be different, but they're already identifiable explicitly by name and OS version.

> Exactly. It's the point of this bug. We don't want a meaningful date there.

Exactly, and I don't think having something meaningless is helpful enough.

> We'd remove the whole thing right now if there were no compatibility concerns.

I think the compatibility concerns need to be better quantified, honestly. I don't know if they're as big as we think. Various people requested real world data on this but did we ever get some hard numbers on how many sites would break due to changes like removing the build date entirely? What about just truncating to Gecko/2010 (year of major Gecko version)? And out of those, how many of those wouldn't fix it really quick?

Comment 35

[Dão Gottwald [:dao]]

(In reply to comment #34)
> I think the compatibility concerns need to be better quantified, honestly. I
> don't know if they're as big as we think. Various people requested real world
> data on this but did we ever get some hard numbers on how many sites would
> break due to changes like removing the build date entirely?

I'm sure there's still an open bug on removing the date. This discussion belongs there.

> What about just
> truncating to Gecko/2010 (year of major Gecko version)? And out of those, how
> many of those wouldn't fix it really quick?

It's not what we want ultimately, it wouldn't even remove the footgun, so I fail to see how it would be worth the effort.

Comment 36

[Dave Garrett]

(In reply to comment #35)
> (In reply to comment #34)
> > What about just truncating to Gecko/2010 (year of major Gecko version)?
> 
> It's not what we want ultimately, it wouldn't even remove the footgun, so I
> fail to see how it would be worth the effort.

It would remove the footgun by not bumping the date automatically with the actual year, which is the core problem that trips up the sniffers. 2011 rolls around and a site panics because it "supports" only the 2010 browser. With a semi-frozen year this wouldn't happen. I say semi-frozen, because we'd then want to bump it for Gecko 2.x (not 2.0.y) to indicate that it is in fact new. This part would be needed because of the fail case in comment 28. This method would then have about the same UA sniffing stupidity potential as any other version component in the UA. Sniffing for Gecko/YYYY would be equivalent in result to sniffing for rv:x.y.

Comment 37

[Dão Gottwald [:dao]]

(In reply to comment #36)
> It would remove the footgun by not bumping the date automatically with the
> actual year, which is the core problem that trips up the sniffers. 2011 rolls
> around and a site panics because it "supports" only the 2010 browser.

That's not the common use case, AFAIK. Sites don't care about your browser's release date. They just happen to match it when attempting to identify Gecko browsers.

Comment 38

[Dave Garrett]

See the oft quoted bug 330418 comment 1 (first quoted by Boris in comment 3):

> See this part of http://www.fly.faa.gov/js_source/xbdhtml.js :
> 
> //Mozilla
>     this.moz12   = (this.gecko && (agt.indexOf('gecko/20021130')!=-1))
> //    this.moz13   = (this.gecko && (agt.indexOf('gecko/20030312')!=-1))
>     this.moz2003 = (this.gecko && (agt.indexOf('gecko/2003')!=-1))
>     this.moz2004 = (this.gecko && (agt.indexOf('gecko/2004')!=-1))
>     this.moz2005 = (this.gecko && (agt.indexOf('gecko/2005')!=-1))
>     this.moz13up = (this.moz2003 || this.moz2004 || this.moz2005)
> //    this.moz131  = (this.gecko && (agt.indexOf('gecko/20030425')!=-1))
> //    this.moz141  = (this.gecko && (agt.indexOf('gecko/20030624')!=-1))

The freakin' US FAA is still checking the year for no good reason. If they were to add a line for "Gecko/2010" it won't break on 2011 like previous lines did, but it may on Gecko 2.next if we bump the Gecko year then, and for all we know it should break because it'd be a different version. Yes yes, we want to maintain compatibility with things forever, but people sniffing aren't as interested in trying that route.

Yes, I know a semi-freeze to "Gecko/2010" won't fix the case of where they're matching something for no good reason at all, but nothing will really fix that except removing the ID entirely, which we would rather do here. For something as bad as above, nothing short of a full rewrite by someone who cares if it continues to work will fix anything. Sometimes a TE bug is actually the best route.

I'm saying "Gecko/20100101" is a worse compromise than "Gecko/2010" and the later avoids the Jan 1st confusion (and saves 4 bytes per HTTP request).

Comment 39

[Benjamin Smedberg]

The only reason we did not remove the date entirely is because we did not want to risk compatibility changes from *known* sites which depend on the precise format of the current string (e.g. we broke these sites for a bit when we added the hour and minute to the buildid). There are then three options:

* remove the Gecko/builddate entirely
* have a real build date
* have the fake build date

We will *not* implement Gecko/2010 or Gecko/2.0 because that just increases the risk for little return in terms of reducing either the size or the UA-sniffing surface.

I believe that we made the right decision here for Firefox 4 and we can consider removing the date entirely in Firefox 5.

Comment 40

[Reşat SABIQ (Reshat)]

(In reply to comment #31)
> No, it also made Linux builds less distinguishable. Win for bug 572650.

Linux builds are still distinguishable, and in general buildID-based fingerprintability issue isn't gong to be resolved until bug 583181 is fixed. UA tweaks only resolve buildID-based fingerprintability 100% for people w/ JS disabled: an estimated 5% in 2008[1]. For users w/ JS enabled, buildID-based fingerprintability is only improved on sites that aren't checking navigator.buildID in JS during a user's browsing (no stats available AFAIK). And any site that wants to continue sniffing buildID will easily do so using navigator.buildID even if they weren't doing so prior to Firefox 4.
The net conclusion is: until bug 583181 is fixed most users will continue suffering from buildID-based fingerprintability.[2]
To wrap up: i'm 50-50 whether it's worth putting users and developers through puzzling and learning about the rationale behind the UA date freeze, w/o fixing the issue 100% (by fixing bug 583181 concurrently). It appears to provide little benefit, at a cost of puzzling and confusing some users and developers for the next year or so (until the date is gone from UA string completely). Even branch-dating buildID in UA would be less confusing than fixed 20100101. IMHO, it would be better to get rid of the date in UA string completely:
a. It would likely avoid another UA string format change in Firefox 5 (at least until 6 or 7 or 8...)
b. It will be less puzzling and confusing for both users and developers.
c. UA format has changed anyway.
d. Silly code has to be fixed by sites sooner or later.
But this has currently been turned down for FF 4.

[1] http://www.w3schools.com/browsers/browsers_stats.asp
[2] The only mitigating circumstance is that perhaps there could be an add-on or some informational service that could warn users in real-time or before or after the fact that the site they visited sniffed their navigator.buildID: which would look sneaky because most sites shouldn't care about it (other than bugzilla, and a few other mozilla sites). But again, most users, and probably developers etc. as well, won't bother with this kind of thing. So this mitigation is likely gonna stay in theory, w/ no real impact on reality.

Comment 41

[Dave Garrett]

(In reply to comment #40)
> Even branch-dating buildID in UA would be less confusing than fixed 20100101.

I'd go with that. Freeze to whatever date 4.0 is officially released. Less dumb.

> IMHO, it would be better to get rid of the date in UA string completely:

Yeah, but and prior discussions ruled that out for the time being.

> (In reply to comment #31)
> > No, it also made Linux builds less distinguishable. Win for bug 572650.
> 
> Linux builds are still distinguishable, and in general buildID-based
> fingerprintability issue isn't gong to be resolved until bug 583181 is fixed.
> UA tweaks only resolve buildID-based fingerprintability 100% for people w/ JS
> disabled: an estimated 5% in 2008[1]. For users w/ JS enabled, buildID-based
> fingerprintability is only improved on sites that aren't checking
> navigator.buildID in JS during a user's browsing (no stats available AFAIK).
> And any site that wants to continue sniffing buildID will easily do so using
> navigator.buildID even if they weren't doing so prior to Firefox 4.

An important point mentioned in other fingerprinting bugs:
server-side-only fingerprintability is a notably bigger deal than in-JS client-side fingerprintability

If a good fingerprint can be created out of only the HTTP request, it's really useful and transparent to the fingerprintee. Client-side techniques not only can be detected and potentially blocked, but are also less relevant because you're already essentially screwed fingerprint-wise on the client side. (more discussion on this could be done, again, but it's not really warranted for this particular bug)

Comment 42

[Reşat SABIQ (Reshat)]

(In reply to comment #41)
> Client-side techniques not only
> can be detected and potentially blocked, but are also less relevant because
> you're already essentially screwed fingerprint-wise on the client side.

If someone stands out in their buildID, as all Linux users do, for instance, they will still be very much fingerprintable: both in terms of AJAX-based dynamic content within the same page, and IP-based cross-site, cross-request user identification, and a combination of the 2. Discuss it or not, whoever wants to fingerprint buildID will easily keep doing that, considering that the majority of users won't even know they are being buildID-fingerprinted, try as we might to raise awareness, until the JS property is not freely accessible to every site.

Comment 43

[Dave Garrett]

(In reply to comment #42)
I didn't disagree with you. There is a client-side fingerprinting issue here, but it's a pebble a the bottom of a very large mountain. One day I might care about it, but for now, I'm saying it's irrelevant in comparison to other much much bigger issues on the client side.

Though, we're now off topic.

Comment 44

[Daniel C]

So this will actually come into play for the first time soon, when Firefox 4 RC1 is created. I'm slightly concerned because this hasn't had an real testing and there is at least an element of risk involved with leaving it as it is which can be partly mitigated without moving away from a fixed date.

Are you sure you want to stick with 20100101 for the fixed date until such a time as it can be removed entirely? I would at least consider a different fixed date.

There is a potential risk in using 20100101, in that someone could perhaps be doing feature detection based on a date later than that. For example, a site checking for Firefox builds that include the readyState property (3.6) and that also have stable OOP plugin instances (3.6.6) could do something like:

if(isFirefox() && document.readyState && dateFromUA() > 20100626) {
  // Do stuff
}

Obviously this is hypothetical and parsing the date string is silly (not that it stops people), but a date that is at least later than 3.6 would be less risky than the current (untested) date.

So how about a simple 20100101 -> 20110101 change? As it stands, 4.0 will have a UA date which is even earlier than 3.6, and no-one really knows whether that will cause problems or not until it is released.

I'm going to reopen and set the blocking flag just so that this gets attention. I had forgotten about it until just now, so I figured that maybe others had too and it's one of the only web-detectable things that will change when transitioning to a release candidate build.

Comment 45

[Reed Loden [:reed]]

New issue == new bug. This one is long-ago fixed.

Comment 46

[Daniel C]

I was also wrong about this not being in any released builds already. I thought that beta builds used a different branding directory from the Firefox one, but that's not the case anymore. Sorry about the spam.

I still think it's a bit bizarre to have a date that is actually earlier than 3.6 and think that 20110101 would be better, but my potential risk case is purely hypothetical and doesn't seem to have been uncovered by the betas.

Comment 47

[Wolfgang Rosenauer [:wolfiR]]

Probably new issue also but just noticed and wanted to comment here as well:

In xulrunner+firefox combinations like they are distributed by some Linux vendors this patch has no effect.

Comment 48

[Dão Gottwald [:dao]]

(In reply to comment #47)
> Probably new issue also but just noticed and wanted to comment here as well:
> 
> In xulrunner+firefox combinations like they are distributed by some Linux
> vendors this patch has no effect.

You need to set MOZ_APP_UA_BUILDID when building xulrunner. Not sure if we should do this by default...