Closed Bug 572661 Opened 14 years ago Closed 12 years ago

Don't expose the Gecko build date in the UA string

Categories

(Core :: Networking: HTTP, defect)

Product:
Core
Component:
Networking: HTTP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla13

People

(Reporter: hsivonen, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: privacy, Whiteboard: fixed by bug 591537)

Attachments

(1 file, 1 obsolete file)

patch v2
1.91 KB, patch
jst
: superreview+
Details | Diff | Splinter Review 
Steps to reproduce:
 1) Load http://www.delorie.com:81/some/url.txt

Actual results:
The compilation date of Gecko is exposed in the UA strin,. which means compilation time-based entropy is exposed and can by used for fingerprinting especially in the case of builds other than MoCo release builds. See https://panopticlick.eff.org/ The date also bloats the HTTP request. Furthermore, the compilation date doesn't tell what code was compiled, so it's the wrong thing to pay attention to for the purpose of bugzilla.mozilla.org bug reporting.

Expected results:
Expected the "Gecko/" string to be followed by the Gecko version and the build date not to be exposed and the old rv: token to be removed. If moving the Gecko version around like that turns out to break too many sites, the second best alternative would be having the string "Gecko/rv:" followed by the version number.

Additional info:
The hg revision from which Gecko was built could be exposed to *.mozilla.org and *.mozilla.com origins via a JS API that'd be uncallable from other origins.
if i remember correctly the "build id in user agent" discussion has been fought more than one time before.
Whiteboard: dupeme
Thumb up for this bug!

Fingerprinting from useragent is too easy and invisible.
And there's no reason why official builds have the official date but source code should have it's date.

It's really no worth if you do this for the debug.
Debug what? A buggy browser? Hehe!
Blocks: 572659
I am not sure this is a good idea. Sites such as Mozillazine list the full user-agent string in the build posts to help identify regressions.

Removing it from nightly builds would take away a feature that can be useful and removing this from release builds will not help as that correlates to the date of the release of the browser.
This also helps identify people that download RC builds in pointing them out that they don't have the actual release.  I almost always look at the date and barely ever look at the actual version number in people's UAs.

I know that argument is mostly for us nightly users but can also be used by the end user.  If they see the date is really old that might prompt them to check for an update if they have the automatic checking turned off.
This shouldn't effect trunk builds. Having the date visible is quite useful.
My first thought is it's a very bad idea for little gain.  I feel some of the reasoning for the bug is flawed as people do have a need the for build ID.
This will make life in various support forums even more difficult.
(In reply to comment #6)
> My first thought is it's a very bad idea for little gain.  I feel some of the
> reasoning for the bug is flawed as people do have a need the for build ID.
> This will make life in various support forums even more difficult.

To add to your post, how's this a privacy bug? What, is somebody gonna take your 
credit card credentials just because they know your build date? 

Bug is INVALID WONTFIX
For release it's not about when browser was released.
But when you built it.

Which means: if you build an unofficial version you'll be fingerprinted easily.
(In reply to comment #8)
> For release it's not about when browser was released.
> But when you built it.
> 
> Which means: if you build an unofficial version you'll be fingerprinted easily.

Then those people are free to remove it from their own builds. This is an invaluable feature for support forums and for nightly testers and thus as such it should not be removed over a trivial privacy issue, even if you can call it such.

Can we call someone up here who can make this call and preferably put this to rest once and for all?
Why are you so in a hurry Ryan?

If you disable the date in your own build it wont help because you're still the only one to have "Gecko" without / something.
Most knockoffs tend to change the UA a lot more than this, they tend to add things like Trident/Safari/Chrome/Opera info and other stuff and don't include the build date anyway.  Removing the date only makes it the same as other regular software.

Can't we hardcode the build from date into the about:dialog, about:support or about:buildconfig instead, or come up with an easter egg.. NTT is really the only support tool that can help otherwise. 

Why not add something that identifies official mozilla engineering date then only built off the mozilla servers.  Having it in there is helpful to single out people who may need an upgrade.
I'm against fixing bug 572659, but I think this bug could be fixed separately and not cause too many problems.

For release builds, this is duplicate information when the version number is also present -> Not needed.

This is also true for alpha and beta builds -> Not needed.

For nightly builds or self-built builds, this is not true. However, this information could be exposed elsewhere (about:support, about:buildconfig along with the changeset, about:, the Help -> About Minefield dialog).

I agree that the build date is very useful, but I don't really see why it needs to be exposed to the web. I'm not even particularly bothered about the fingerprinting aspect, as for release builds this information adds no new identifiability, and us nightly users are generally screwed in that aspect anyway. I think this is more along the lines of bug 572668 in that it doesn't really help against fingerprinting but it's good to get rid of unnecessary stuff.

Kurt made a point about the date being a sign that your build is old for people that have automatic checking turned off, but that's not much of a reason to keep it around.

And just for reference (because it took me a while to find these) the bug that changed the UA-visible build IDs from YYYYMMDD to YYYYMMDDhh was bug 383167. The bug that changed it to the full YYYYMMDDhhmmss format was bug 431270, and the bug that changed it back to YYYYMMDD again was bug 450973).

Note that Benjamin alluded to this bug back in 2007 with bug 383167 comment 16 and bug 387163 comment 8.
I don't quite understand the rational of sending more data over http makes sense in the space of the fast internet.

Maybe we could even modify the nightlies so that it populates a pref like general.useragent.extra.[MozBuilddate] and then you could remove it from the regular UA under the official releases manifest or whatever.  Its main helpfulness is in testing nightlies, or just make it populate the general.useragent.override pref to be for a custom nightly string.. any of these seem more sensible than dropping it completely, then reset the pref when building an official release build.
(In reply to comment #12)a builds -> Not needed.
> I'm not even particularly bothered about the
> fingerprinting aspect, as for release builds this information adds no new
> identifiability, and us nightly users are generally screwed in that aspect
> anyway. I think this is more along the lines of bug 572668 in that it doesn't
> really help against fingerprinting but it's good to get rid of unnecessary
> stuff.
> 

Not nightlies. What about users of custom (released) versions?
(In reply to comment #6)
> This will make life in various support forums even more difficult.

Firefox *nightly* support forums are very, very few. Making the browser more fingerprintable because a *very* small number of sites get their use case addressed is an awfully bad tradeoff, IMO.

Note: I think it's OK to expose the build date, hg revision, etc. to the user in the about box or in about:buildconfig for copying and pasting to nightly support sites.
I still don't understand what the argument is for removing this.  It doesn't hurt anybody, doesn't expose any private information, it helps out a lot of people with support issues, removing this could break lots of sites, could help notify users that they are using very old builds...

It just seems like there is no benefit in removing this while there is a moderate risk for breaking sites.
(In reply to comment #16)
> I still don't understand what the argument is for removing this.  It doesn't
> hurt anybody,

It makes the users of builds that aren't Mozilla Corporation release builds (i.e. self-build versions, nightlies or release version builds made by others than Mozilla) more fingerprintable than if this date weren't exposed.

Furthermore, it provides more sniffing surface for sites so that users with unusual build dates can end up with different site behavior than users with the *same code* but a different build date.

> doesn't expose any private information,

It's not private information as such, but it exposes entropy for fingerprintability. See https://panopticlick.eff.org/

> it helps out a lot of people with support issues, 

See comment 15.

> removing this could break lots of sites,

Yes. Freezing it to a constant (e.g. 20110101) wouldn't break sites, though.
(In reply to comment #17)
> (In reply to comment #16)
> > I still don't understand what the argument is for removing this.  It doesn't
> > hurt anybody,
> 
> It makes the users of builds that aren't Mozilla Corporation release builds
> (i.e. self-build versions, nightlies or release version builds made by others
> than Mozilla) more fingerprintable than if this date weren't exposed.

I doubt Mozilla will consider self-builds or release builds as used by others as an argument in this case since those are not the responsibility of Mozilla to handle.

As for nightlies they are useful, as has been expressed many times here and on Mozillazine.

> 
> Yes. Freezing it to a constant (e.g. 20110101) wouldn't break sites, though.

That sill provides no help to nightly testers and support forums who use the build dates to track down bugs, regressions and advise people.

Removing something that is useful is a bad, bad idea. Add an option to disable it somewhere and disable it by default - let the people who think they are being tracked disable it manually.

Does anyone happen to know who would be able to make the call if this should be done or not?
(In reply to comment #18)
> (In reply to comment #17)
> > (In reply to comment #16)
> > > I still don't understand what the argument is for removing this.  It doesn't
> > > hurt anybody,
> > 
> > It makes the users of builds that aren't Mozilla Corporation release builds
> > (i.e. self-build versions, nightlies or release version builds made by others
> > than Mozilla) more fingerprintable than if this date weren't exposed.
> 
> I doubt Mozilla will consider self-builds or release builds as used by others
> as an argument in this case since those are not the responsibility of Mozilla
> to handle.

In general (for things everything other than the build date and the product name in the UA string), Mozilla doesn't make the codebase do undesirable things when built by someone other than Mozilla Corporation, so saying it's not Mozilla's responsibility isn't a good reason not to have sensible behavior in the code base by default.

> As for nightlies they are useful, as has been expressed many times here and on
> Mozillazine.

I'm not denying that there is a use case. I'm saying that the fingerprintability concern should override the utility of exposing the date to support sites in the UA string. It's a tradeoff.

Note that the build date could still be displayed to the user in the about box (or could be made available to support sites via an API that checks which origin is calling it).

> > Yes. Freezing it to a constant (e.g. 20110101) wouldn't break sites, though.
> 
> That sill provides no help to nightly testers and support forums who use the
> build dates to track down bugs, regressions and advise people.

Correct.

> Removing something that is useful is a bad, bad idea. Add an option to disable
> it somewhere and disable it by default - let the people who think they are
> being tracked disable it manually.

No offense, but it seems to me that you missed the point of how fingerprinting works. If most people have a build date there, the absence of the build date is in itself a bit of fingerprintable data.
(In reply to comment #19)
> In general (for things everything other than the build date and the product
> name in the UA string), Mozilla doesn't make the codebase do undesirable things
> when built by someone other than Mozilla Corporation, so saying it's not
> Mozilla's responsibility isn't a good reason not to have sensible behavior in
> the code base by default.

True. But this is a minor, minor issue, if you can even call it such. So long as the version number remains in release builds the build ID is pointless removed. In nightlies it is useful and should not be removed anyway.

> 
> I'm not denying that there is a use case. I'm saying that the
> fingerprintability concern should override the utility of exposing the date to
> support sites in the UA string. It's a tradeoff.
> 

It's a trade off that has no value in my opinion anyway.

> Note that the build date could still be displayed to the user in the about box
> (or could be made available to support sites via an API that checks which
> origin is calling it).

Doesn't that defeat the point of removing this, so long as it is available to the sites in anyway then there is a "privacy" issue there - unless something is done along the same lines as the geolocation...

> 
> No offense, but it seems to me that you missed the point of how fingerprinting
> works. If most people have a build date there, the absence of the build date is
> in itself a bit of fingerprintable data.

I know how it works, I have used such a system in the past for testing security. However is minimal fingerprinting is what is needed here, just do full hog and just use Mozilla Firefox/4 as the user agent string. Unless you are going to suggest going that far then there is no need to do this.
(In reply to comment #18)

> I doubt Mozilla will consider self-builds or release builds as used by others
> as an argument in this case since those are not the responsibility of Mozilla
> to handle.

Have you considered embeders and the like ? E.g Camino.

Comment 15
> removing this could break lots of sites,

having the date in there also broke sites. Search TE bugs for Yahoo and the new year bug. There was also a TE bug for Versiontracker. 2 relatively high profile cases

Comment 18  
> As for nightlies they are useful, as has been expressed many times here and on
> Mozillazine.

I won't argue that knowing the build-date isn't useful. But as has been argued already, the about box is the perfect location for that. (Iirc, that is where you can find the exact version of IE on Windows you are running - patch level and all that. The UA string doesn't tell you that.)
(In reply to comment #20)
> > Note that the build date could still be displayed to the user in the about box
> > (or could be made available to support sites via an API that checks which
> > origin is calling it).
> 
> Doesn't that defeat the point of removing this, so long as it is available to
> the sites in anyway then there is a "privacy" issue there - unless something is
> done along the same lines as the geolocation...

No, it doesn't defeat the point if the API allows only support site origins (either by Mozilla shipping a list of authorized support sites as a pref or by starting with an empty list of authorized sites and letting the user authorize any site as with geolocation).
Ok, so I see the points and very well articulated I think, The more data has to be stored in servers when sending the UA, and it does pose a risk for UA sniffers with website compatibility, removing it should help that cause.  In the case of Mozillazine we're lucky to be able to see everyone's UA there for support, most sites, unless forum based don't show this, and yes it will force people to ask more often, that I'm not happy about but, the one other place I see it is in the titlebar on Nightlies, though you cannot copy/paste, but its nice to have on nightlies.

So in light of all the pros/cons mentioned, It would be nice to see this in action and how this would work with the about: dialog, that seems like a sensible alternative, considering Windows is likely to put the check for updates in there too for fx4.
The only other thing is bugzilla doing js API to find it, I think we'll still need it for that.
Henri: there are tons of ways to track users, not clear why this one is the straw that is breaking the camel's back.

/be
Yes there are tons: why fix this bug?
I think this bug stands on it's own regardless of fingerprinting issues. There is no reason this needs to be sent over the wire for every single HTTP request. For support reasons, there are plenty of places this could be (about:support, about:, about:buildconfig, the Help -> About box).

As Dale mentioned in comment 24, people using the Bugzilla Helper for new bugs will lose the automatic discovery of the build date. The text there already says: "If the above field is blank or you know it is incorrect, copy the version text from the product's Help | About menu". For release builds, this doesn't matter as the build date is implied by the version number. Nightly users will have to do a quick copy and paste, but I would guess that most nightly bug filers don't use the helper anyway and already copy and paste from the About box.

Anything based on the 1.9.0 branch already has, or had, a different date format (2 extra digits for the hour) so I think sniffers are already slightly flexible, and if not, are quite possibly broken already due to changes such as bug 572656 and bug 572668.

The Gecko string is often sniffed for simply by doing a UAString.indexOf("Gecko") test which is why WebKit-based browsers have "KHTML, like Gecko" in there. Therefore the Gecko string couldn't and shouldn't be removed, but it could either be on it's own, or the Gecko version could be moved from the rv: part to where the build date is now.

Note that bug 181046 was filed and fixed to remove 8 bytes from request headers (although 1 of them was added back again in bug 576033). This fix could remove 9 bytes (including the slash) which serve no purpose to the web at large.

To fix this, I think netwerk/protocol/http/nsHttpHandler.cpp needs a minor change. It already does:

647         if (!mProductSub.IsEmpty()) {
648             mUserAgent += '/';
649             mUserAgent += mProductSub;
650         }

So all that needs to be changed/removed is:

302     nsCOMPtr<nsIXULAppInfo> appInfo =
303         do_GetService("@mozilla.org/xre/app-info;1");
304     if (appInfo)
305         appInfo->GetPlatformBuildID(mProductSub);
306     if (mProductSub.Length() > 8)
307         mProductSub.SetLength(8);
(In reply to comment #17)
> > removing this could break lots of sites,
> 
> Yes. Freezing it to a constant (e.g. 20110101) wouldn't break sites, though.

Sure it would (see below).  Let's just kill it.

(In reply to comment #25)
> Henri: there are tons of ways to track users, not clear why this one is the
> straw that is breaking the camel's back.

It also would eliminate the ability for stupid webdevs to do stupid things like http://www.ardisson.org/afkar/2009/01/01/and-the-winner-is…/ and http://www.ardisson.org/afkar/2010/02/07/and-the-winner-is…-2/ and therefore continually break their sites in Gecko browsers every year (there are some other bugs in TE about sites continuing to do this stupid thing--one believes that Gecko only goes up to 2006, iirc--but I don't have the time to look them up right now).

As mentioned in the original newsgroup thread, and as alluded to earlier by Henri, I would like some sort of private API to expose this only to our product sites so that we can continue to chasten users of old nightlies, which, along with Bugzilla Helper and the like, is the only legitimate purpose exposing the build date to the web has served in recent years.  Those are minor use-cases, and easy-enough fixed (or worked-around, in the support case), and they shouldn't be used to block removing this useless stupidity from the UA.
Those sound like good reasons apart from the fingerprinting bête noire. dbaron, anyone: opinions
> (In reply to comment #28) sort of private API to expose this only to our product
> sites so that we can continue to chasten users of old nightlies, which, along
> with Bugzilla Helper and the like, is the only legitimate purpose exposing the
> build date to the web has served in recent years.  Those are minor use-cases,
> and easy-enough fixed (or worked-around, in the support case), and they
> shouldn't be used to block removing this useless stupidity from the UA.

How would this cover valid other use cases outside of Mozilla product sites like forums, help desks, or administrators in an enterprise setting trying to hunt down users not maintaining their laptops properly with regular updates?
(In reply to comment #30)
> > (In reply to comment #28) sort of private API to expose this only to our product
> > sites so that we can continue to chasten users of old nightlies, which, along
> > with Bugzilla Helper and the like, is the only legitimate purpose exposing the
> > build date to the web has served in recent years.  Those are minor use-cases,
> > and easy-enough fixed (or worked-around, in the support case), and they
> > shouldn't be used to block removing this useless stupidity from the UA.
> 
> How would this cover valid other use cases outside of Mozilla product sites
> like forums, help desks, or administrators in an enterprise setting trying to
> hunt down users not maintaining their laptops properly with regular updates?

That shouldn't apply if your trying to run release build in such settings, you already have product version numbers and the gecko #, we're talking the build date attached at the end of the UA, not the version numbers or gecko number here.
(In reply to comment #30)
> > (In reply to comment #28) sort of private API to expose this only to our product
> > sites so that we can continue to chasten users of old nightlies, which, along
> > with Bugzilla Helper and the like, is the only legitimate purpose exposing the
> > build date to the web has served in recent years.  Those are minor use-cases,
> > and easy-enough fixed (or worked-around, in the support case), and they
> > shouldn't be used to block removing this useless stupidity from the UA.
> 
> How would this cover valid other use cases outside of Mozilla product sites
> like forums, help desks, or administrators in an enterprise setting trying to
> hunt down users not maintaining their laptops properly with regular updates?

Those are not valid user cases. Nobody should be allowed to use that cabbalistic API except mozilla trusted sources, on which mozilla should be able to have a good control.

Or we missed the point of having a private API.
If that's really important (and I don't see the importance, other browsers don't have such a thing).
(In reply to comment #28)
> As mentioned in the original newsgroup thread, and as alluded to earlier by
> Henri, I would like some sort of private API to expose this only to our product
> sites so that we can continue to chasten users of old nightlies, which, along
> with Bugzilla Helper and the like, is the only legitimate purpose exposing the
> build date to the web has served in recent years.  Those are minor use-cases,
> and easy-enough fixed (or worked-around, in the support case), and they
> shouldn't be used to block removing this useless stupidity from the UA.

Removing the build id from the UA may well be a valid exercise, but I'm strongly opposed to a private API that exposes this data only to mozilla sites. Such a feature could easily be misconstrued as more of an invasion of privacy than it really is. Furthermore, many mozilla sites that would want the build id aren't served over https (and in the case of the nightly build startup page, aren't likely to be served over https anytime soon), so there's no secure way to limit this "private API" to MoCo only sites. Also, it does nothing to help mozillazine and other community sites. 

I'll point out that we have the navigator.buildID property (javascript:alert(navigator.buildID)) from bug 345993 to make the full build id (the one in the UA is truncated) accessible to tools like Bugzilla and Litmus. Removing it from the UA without removing navigator.buildID helps with the UA length issues, but maintains privacy concerns. Removing the build id from the UA and nuking it from the navigator object aids privacy, but poses a real problem for testing and bug reporting.
(In reply to comment #25)
> Henri: there are tons of ways to track users, not clear why this one is the
> straw that is breaking the camel's back.

Whatever is the first step towards less trackability could always be argued against by pointing at all the other tracking mechanism. If Mozilla is as serious about trackability in general as Mozilla appears to be about third-party cookies, something needs to be the first step. If all steps need to be taken in unison, we'll never take any steps.

But considering non-fingerprinting issues for a moment:

The use cases addressed by the build date are ridiculously narrow compared to the how widely the data is sent. The normal Bugzilla bug reporting workflow isn't sensitive to the build id. Only the Bugzilla Helper is. So for the date to be useful, the user has to
 1) Be using a MoCo nightly.
AND
 2) Opt in to using Bugzilla Helper.
AND
 3) Use the build that the bug appears in to report the bugs as opposed to using a release build or another browser to report bugs about the build that's faulty.

I had a look at the MozillaZine forums, but I didn't see the build date in the forum posts, so I guess the forum doesn't automatically take it from the UA string. I had a look at the SUMO forums, but all open questions there seem to be from users of release builds, so the build date is redundant data.

Since the use case being addressed is so narrow and so specific to Mozilla's own systems (as opposed to being a more general Web need), I think the build date shouldn't have been exposed to all the Web in the first place.

Apart from fingerprinting, any piece of data exposed in the UA string is bad in two ways:
 1) More bytes sent in each request.
 2) More sniffing surface.

#1 isn't helped if the build date is frozen as opposed to being removed. However, it seems to me that removing it would have too drastic compat effects, so my current proposal is freezing it, so no bytes would be saved, so I'm not arguing point #1 further.

As for point #2: *Any* variable piece of data in the UA string is an opportunity for site authors to do something silly and cause grief to users, QA and developers. Whatever is exposed for whatever purpose (be it Bugzilla helper, enhancing software download experience by exposing stuff like WOW64 or enabling sites to compile statistics for curiosity), that piece of data can be used as input for a cluelessly framed |if| statement which leads to user unhappiness or more time-consuming/expensive QA/developer cycles when trying to figure out why a given problem occurs with one build but not with another. Comment 28 has a concrete example.

For this reason, even if we didn't care about fingerprinting, we should have as little variability as feasible in the data the browser exposes about itself to sites. This can be achieved either by removing data or by freezing it so that it no longer varies.

That is, I think the inconvenience of the craziness pointed to by comment 28 (that can happen anywhere on the Web) should outweight (even more so when considering also fingerprinting) the convenience of streamlining Mozilla's own bug filing or support processes (that take place on a handful of sites). (Clearly, others disagree with me.)
(In reply to comment #34)
> If Mozilla is as
> serious about trackability in general as Mozilla appears to be about
> third-party cookies, something needs to be the first step. If all steps need to
> be taken in unison, we'll never take any steps.

I should mention that I realize that taking any steps is pointless if there's utility only once all steps have been taken and you know you can never take all the steps. However, even if we believed that we can never close down the Flash loophole, I think there'd still be benefit in closing down the ability to do pure server-side fingerprinting.
> (In reply to comment #32) Those are not valid user cases.

Not for such a hypothetical API, but certainly for the use cases I mentioned.

(In reply to comment #31)
> That shouldn't apply if your trying to run release build in such settings, you
> already have product version numbers and the gecko #, ...

Not if Henri gets all of his wishes fulfilled. ;-)  [that's bug 572659]

(In reply to comment #33)
> strongly opposed to a private API that exposes this data only to mozilla sites.
> Such a feature could easily be misconstrued as more of an invasion of privacy
> than it really is.

Agreed.

> I'll point out that we have the navigator.buildID property

So that's a similar loophole for the date as "Accept-Language:" is for the attempt to hide the locale in bug 572656, maybe less easy to utilize.

(In reply to comment #34)
> I had a look at the MozillaZine forums, but I didn't see the build date in the
> forum posts, so I guess the forum doesn't automatically take it from the UA
> string. I had a look at the SUMO forums, but all open questions there seem to
> be from users of release builds, so the build date is redundant data.

You are commenting on a system that you apparently don't understand. All the phpBB3 boards present the UA string to registered users who are logged in and are willing to help, to provide them with the necessary information to support the answer. In contrast, GetSatisfaction doesn't, so it's always happy platform guessing over there.
(Quoting Karsten from bug 572659 comment #15)
> Note also that Thunderbird sported a minimal UA for some time and ruefully
> restored it. I see no point in hiding helpful information when you're even more
> recognizable by fingerprinting fonts and addons. And security by obscurity is a
> myth.
In the interest of this bug not getting completely side tracked from the build
date issue, I think Henri has a good point that we should start somewhere.  So with that in mind, there are bugs open for many issues, not just the build id.  This is not the only one.  

We should spin off the API issue to another bug.
(In reply to comment #37)
> (Quoting Karsten from bug 572659 comment #15)
> > I see no point in hiding helpful information when you're even more
> > recognizable by fingerprinting fonts and addons. 

That is partly bug 581008.
Yes, that bug only appeared this morning though...

(In reply to comment #38)
> In the interest of this bug not getting completely side tracked from the build
> date issue, I think Henri has a good point that we should start somewhere.

I also think that KaiRo has an extremely good point in bug 572650 comment #20 (meta bug), sites will be broken by changes in the UA string which aren't expected by whatever scripts these sites run for identification purposes.
Simply changing long-standing formats for UA-string items isn't going to work unless the user has some "compatibility switch" to make the site work again.

The proposal here to remove the date string and possibly move the rv: info there instead, thus resulting in a Gecko/rv:x.x.x token, would be such a significant change. Even if you leave the rv: untouched and just make it Gecko, a site sniffing for "Gecko/" to distinguish it from Safari's "(like Gecko)" would break things already.

So, changes like this should be deferred until it is clear how to provide a fallback for the user, that should be the baseline to start from.
I think the change proposed in this bug is a good one; making the UA string shorter is a good thing (for both reasons Henri gives in comment 34: bytes sent over the wire and unneeded sniffing surface).

I don't think the change proposed here, alone, does anything to help fingerprinting, except when JavaScript is disabled.  We still have navigator.buildID, and even if we didn't, somebody who cared could use feature detection and bug detection to figure out build IDs quite accurately (particularly if they looked at, say, automated tests regularly checked in to our tree).

(Also, for fingerprinting, I think the useful information is not necessarily what version the user is on, but what update stream they're on.  If a site tracks a regular user using cookies, it should be relatively straightforward to figure that out at some point, and then compare the fingerprint to similar fingerprints gathered by other sites.)
(In reply to comment #41)
> I don't think the change proposed here, alone, does anything to help
> fingerprinting, except when JavaScript is disabled.

(Henri Sivonen in bug 572650 comment #12)
> Also, entropy in the HTTP requests enables fully server-side fingerprinting.
> Fingerprinting methods that require sending code the the client side expose
> evidence of the fingerprinting activity meaning fingerprinters can be called on
> their activity.

I tend to agree with this argument and weigh server-side fingerprinting higher than client-side to some degree. Removing the build date helps with this for nightly users even if it is left accessible via JS still. (and a whitelist of some kind is overkill) Arguably, though, we care more about stable (and beta) users for which this change would have no fingerprintablity effect.

Removing one special fingerprinting case and reducing a little HTTP request bloat is nice, but I'm most swayed now by the remove the foot-gun argument to get rid of the ability to UA sniff by date like an idiot. (comment 28)
Whiteboard: dupeme
(In reply to comment #41)
> I don't think the change proposed here, alone, does anything to help
> fingerprinting, except when JavaScript is disabled.  We still have
> navigator.buildID, and even if we didn't, somebody who cared could use feature
> detection and bug detection to figure out build IDs quite accurately
> (particularly if they looked at, say, automated tests regularly checked in to
> our tree).
The 2nd sentence contains a fairly big hypothetical, but even if we assume that 
that hypothetical is a real vulnerability, it's still big time worth reforming or
abolishing the build date, for reasons outlined below.


Sorry for quoting myself from bug 57555, but for me this is the primary reason for wanting the 
"Gecko date reform or abolition".
(In reply to comment #62)
> A core requirement, IMHO, is the following:
> Either mozilla apps themselves should implement an option for user to mask
> their real OS/platform, or they have to, at a minimum, enable extensions to do
> so in a fashion that accounts for update/minor versions and various platforms,
> including a "dynamically-masked" User-Agent string (i.e., not just hard-coding
> the override property, because it will be becoming obsolete in several weeks).
> 
> It's a requirement because even for English telling everybody on the Internet
> that you are in a group of 1 or 2 out of 100 users, is not good from privacy
> viewpoint. Imagine the same for various other locales?
> 
> From this viewpoint, the problem w/ having any kind of date, is:
> vendors (e.g., Ubuntu) are likely to have their own date...

... which means, it's impossible to avoid being identified as a member of 1 or 2% 
of computer users when using a Linux distro, for instance (you have to also use Windows, 
and update that installation, then copy the UA string, and set the override on the Linux
installation every few weeks manually; i don't believe this can be considered a work-around, 
because of continuous nuisance involved, plenty of room for making a mistake, and making, say, 
a Linux user have to use Windows as well).

Some relevant prior discussion of this subject:
https://bugzilla.mozilla.org/show_bug.cgi?id=57555#c59
https://bugzilla.mozilla.org/show_bug.cgi?id=57555#c62
(Ben's suggestion of using branch date:)
https://bugzilla.mozilla.org/show_bug.cgi?id=57555#c63
https://bugzilla.mozilla.org/show_bug.cgi?id=57555#c64
To summarize all suggested approaches:
1. No date: Gecko
2. Branch date: Gecko/yyyymmdd
3. Fixed once and for all date (approach suggested by Henri here): Gecko/20110101

No date would of course be the best, and now is the best time to do this, because there is a User-Agent 
string revolution underway anyway. Just like in history there shouldn't be a revolution every year, 
in software a User-Agent format change should not be done every year. It's set to change for FX 4, so now 
IS the time to make this change. Not doing it now, and realizing that it should have been done next year 
would be a crime against common sense.
Approach 2 is just as good for my use-case (Ubuntu, and customization of UA for Windows, for instance), 
but leaves some concern about whether vendors will actually stick to it (effectiveness and enforceability might not be guaranteed).
Approach 3 might be a tad clearer for effectiveness and enforceability, but it still doesn't guarantee it, and 
of course it would be a bit silly to have 9 totally wasted bytes in the string. But i think this approach is still 
acceptable if it's adopted w/ a deprecation notice saying that the date will be totally gone within [1|2|3] years.

Finally, reforming and abolishing Gecko date is more important than dropping minor version to me, because 
there is a clear every-day average Joe use-case where Gecko date is hurting people's privacy, whereas minor 
version is more hypothetical. 

I would even consider it appropriate to expand the versioning format to account for build date for nightlies
in the version, 
and then reform or abolish the Gecko date. Whatever takes care of the use-case above, is acceptable IMHO. But 
doing nothing about Gecko date as it's puked all over the place today, is completely, utterly, and absolutely 
unacceptable.
FYI: logged Bug 583181 for navigator.buildID to not be revealed to every site on the web.
Filing a bug to make releases have a fixed Gecko date based on the date the release was tagged would also make sense as a separate bug; that would address the issue of Linux distros using different dates for different distros.
(In reply to comment #45)
> Filing a bug to make releases have a fixed Gecko date based on the date the
> release was tagged would also make sense as a separate bug; that would address
> the issue of Linux distros using different dates for different distros.

IMHO, this now appears to be a part of this bug, although it was originally suggested by Ben in bug 57555 (https://bugzilla.mozilla.org/show_bug.cgi?id=57555#c63), following some of my "motivating by disparaging rant" in that bug. If a new bug is logged for that, then it would mostly overlap w/ this bug: if that one is fixed, then this is WONTFIX, and vice-versa. Not sure, maybe it makes sense, maybe it doesn't. Perhaps it makes more sense to make the title of this bug more generic, like "Reform or abolish Gecko build date in the UA string". I can't think of any mutually exclusive bugs, but maybe they do exist...
Resat, We are not trying to create another general UA bug or duplicate bug 57555. 
1 issue per bug please.
Blocks: 584683
The date in the UI has always been a botch. It was conceived to represent the _source_ date, so that Gecko-based products from different sources--e.g. Netscape vs. Mozilla--could be compared (for compatibility, bug workarounds, whatever). As implemented, however, it's always been the _build_ date which meant the exact same engine ended up with different UA strings. Useless! We then started developing from long-lived branches, so Gecko/date means even less than nothing for any compatibility purpose unless you also use the branch. The branch is in the UA (in a couple of places, effectively) but in different tokens which makes no syntactic sense. The UA rfc specifies "product/version (optional_comment)" tokens, but gecko's date is not a version.

Kill the rv: botch (added to compensate for the useless Gecko date when we started long-lived branches) and make the Gecko product token a true Gecko/version token.
"The date in the UA", of course, not "UI".
(In reply to comment #41)
> I think the change proposed in this bug is a good one; making the UA string
> shorter is a good thing (for both reasons Henri gives in comment 34: bytes sent
> over the wire and unneeded sniffing surface).

(In reply to comment #48)
> Kill the rv: botch (added to compensate for the useless Gecko date when we
> started long-lived branches) and make the Gecko product token a true
> Gecko/version token.

Do you think this is Gecko 2.0 material? Are we going to bear a potentially large number of broken sites until people fix up their sniffing code?
If not Gecko 2.0, what then? Gecko 2.0 was explicitly said to break stuff.
(In reply to comment #51)
> If not Gecko 2.0, what then? Gecko 2.0 was explicitly said to break stuff.

That does not justify bearing any cost including suicide.

We need to know about what might break and why. Does anyone have data?

/be
> That does not justify bearing any cost including suicide

hihi

> We need to know about what might break and why. Does anyone have data?

I don't have data, but there is or could be tool which browses the top1000 websites, or a random sample of websites, and makes screenshots of the pages. You do that a second time, with pref general.useragent.override set. Then you compare the screenshots, per script of course.

That doesn't help with highly interactive applications like gmail. You can however also test by just setting general.useragent.override = "Gecko/1.9.3 (Linux)" yourself and running with that for a longer time and see whether there's any noticeable problem. I'll do just that.
i can do a testrun to check if this breaks something - i have a topsite automation for all platforms here.
Blocks: 586165
Carsten, this is a high priority since we need to get these changes into beta 5. (See bug 586165.) Not asking you to drop anything important for this, but if you do happen to have data -- or have a bit of time to gather it -- that would be the most helpful thing that could happen in this bug.
Blocks: 588909
I'm going to play devil's advocate here and produce a patch. There's been lots of discussion here on pros and cons, from which consensus seems to be it's a good idea. We can never be sure as to the scope of what this will break and what it won't; the only way to gather that data reliably on the scale that we need is to try it. The beta audience is sufficiently large to do so. There have been specific anecdotes of breakage, but that doesn't give us a reliable indicator of the wild.
Assignee: nobody → dwitte
Attached patch patch (obsolete) — — Splinter Review 
This removes the buildid and the ability for people to add it back to the UA (via the SetProductSub() method). The latter is kinda preempting more changes like bug 588909, but I could leave it in (for this bug) so that embeddors can add it back. (Note that we're moving in the direction of disallowing UA modifications -- see bug 581008.)
Attachment #467547 - Flags: superreview?(jst)
Attachment #467547 - Flags: review?(jduell.mcbugs)
I'm going to point out once again that a lot of people are very against this change - as is pointed out here. Is there any way of redacting the decision made here?
No point in rehashing the good points that've already been made, in both directions.
While I personally consider won't-fixing bug 572659 on the minor Gecko version more important than the build date, in order to have at least some indicator which version (and these days with which supported features) is used, the exact build date is mostly relevant for nightly testers.

As a bare minimum, the patch should have a preference setting which allows the build date to be retained in mProductComment, thus allowing a user who desires to expose that information in the UA string (frequently followed in forums) as

  Gecko (20100819)

or, possibly after landing of bug 588909,

  Gecko/2.0b5pre (20100819)

This should still be within the scope of this bug and follow the discussion.
Adding hidden prefs that very few people will ever use is not a good idea. The only people that use them would do better to just get the info some better way.
Two options:

1) Copy-paste the data in about:support. This provides a lot more info than the UA can, and is vastly preferable for support uses.

2) Provide a pref as you say, which people can either twiddle themselves or install an addon to do so.

I don't really care which we do, either sounds fine to me.
(In reply to comment #61)
> Adding hidden prefs that very few people will ever use is not a good idea. The
> only people that use them would do better to just get the info some better way.

Not necessarily. Enabling them for nightly / preview testers would let the testers get the benefits of the build date and it could be disabled for end release users.

That would work and make the preference useful no?
It would be off by default of course and comes at no cost for regular users. Another option might be to configure at build time or base on the update channel to restrict it to the nightly builds, but then it would no longer be
a voluntary choice.
Attached patch patch v2 — — Splinter Review 
Nevermind, I think I'm going to make this minimalist -- no change to how the field works; we just don't populate it with the date by default.
Attachment #467547 - Attachment is obsolete: true
Attachment #467573 - Flags: superreview?(jst)
Attachment #467573 - Flags: review?(jduell.mcbugs)
Attachment #467547 - Flags: superreview?(jst)
Attachment #467547 - Flags: review?(jduell.mcbugs)
So, how could a user or an extension get the date included, especially as you
do no longer want to utilize the Gecko/* for the revision? (bug 588909)

It seems to be a straight-forward extension of your current patch to make the code you remove conditional on a hidden pref per comment #63 variant #2, and likely easier than copy-pasting information every time when posting (per #1).
Just make an extension that calls nsIHttpProtocolHandler.productSub with the buildID.
I just wanted to add that it would be nsIHttpProtocolHandler.productComment in case bug 588909 occupies productSub after all, but then noticed in bug 581008 that the patch there would remove productComment completely. On top of that, it would make all relevant nsIHttpProtocolHandler read only, so this workaround is no longer available after both patches checking in.
Compromise suggestion: no build date on release builds but keep the date for nightlies. This gets rid of the easily abused sniff surface, by and large, but keeps the date for posting in bugs and support. This would ignore the fingerprinting argument, but I think it's a fair tradeoff.
Possibly, but we want to keep release and testing builds as similar as possible with regard to how the web interacts with them, c.f. replacing 'Minefield' with 'Firefox'. Changing the format of the UA string goes against that.
What's wrong with <about:buildconfig>? We can put whatever we want there.
Since it appears to have been established that nightlies and testers are the only or the main use-cases of buildId, and there is bug 583181 that exposes the same, actually even more detailed (hhmmss), data, the following appears to be a true statement:

If testers of nightlies don't have to disable javascript for some currently, or expected in the future to be, required testing, or if they were to be required to enable it back after performing such testing (for reporting or discussion, in particular), it is 100% OK to completely remove buildID from UA string, because the use-case will be still be accounted for by js property.

Note, that i'm not asking to resolve both issues at ones (it makes more sense to have separate patches), but the 2 bugs are inter-dependent, so it might make sense to consider both aspects for whichever one (apparently this one) is fixed first. Ideally, both issues should be fixed for Firefox 4, but fixing this one just to settle on UA string format is a good thing regardless, despite not completely resolving privacy concerns involved.

P.S. IMHO, it is OK to simplify the fixing of one, and complicate the fixing of the other, as long as the complication of the fixing of the other one doesn't become excessive or insurmountable. In general, it appears the fixing of the js bug is expected to be more difficult: assuming manual lookup isn't adopted, a certificate-based approach, enabling js property for nightlies only, or a one-time per-site user prompt are among mentioned options.
(In reply to comment #71)
> Possibly, but we want to keep release and testing builds as similar as possible
> with regard to how the web interacts with them, c.f. replacing 'Minefield' with
> 'Firefox'. Changing the format of the UA string goes against that.

I'm suggesting an extra for nightlies, not a change, per se. Any sniffing will be done against the stable UA strings and thus an additional token that's not in the way should probably be fine. Add it as a parenthetical or something à la comment 60:

Mozilla/5.0 (OS) Gecko/rv:ver (builddate) Application/appVer
vs. the following for stable:
Mozilla/5.0 (OS) Gecko/rv:ver Application/appVer
(In reply to comment #74)
> Mozilla/5.0 (OS) Gecko/rv:ver (builddate) Application/appVer
> vs. the following for stable:
> Mozilla/5.0 (OS) Gecko/rv:ver Application/appVer

I guess the concern is broken regex (groups)...
(In reply to comment #75)
> (In reply to comment #74)
> > Mozilla/5.0 (OS) Gecko/rv:ver (builddate) Application/appVer
> > vs. the following for stable:
> > Mozilla/5.0 (OS) Gecko/rv:ver Application/appVer
> 
> I guess the concern is broken regex (groups)...

Appending extra groups as in
Mozilla/5.0 (OS) Gecko/rv:ver Application/appVer (builddate)
might break less frequently, but could still break for those matching anything for the last group (and could get messy if there were more than 1 possible optional extra groups)...
In reply to comment #76 and taking into account bug 588909 comment #18:

This would be more sniffer breaking resistant:

Nightly:  Mozilla/5.0 (OS; builddate; Gecko/rv:ver) Application/appVer
Release:  Mozilla/5.0 (OS; Gecko/rv:ver) Application/appVer
Decided that we're doing this. We could potentially add it back for Minefield builds, but we don't need to decide that right now.
Status: NEW → ASSIGNED
Attachment #467573 - Flags: superreview?(jst) → superreview+
Please file and fix a bug on displaying this information somewhere else. It's currently in Help -> About and about: so I think it should be in at least those 2 places. about:buildconfig would probably make sense (add "Build date:" below "Built from:"). about:support too. Thanks.
Filed bug 589444 about re-adding the info to about:*
Re patch here:
Please see 588909 comment 14.
Please correct me if i'm wrong, but my understanding is that WebKit (or Safari) can still be distinguished from Gecko and Firefox (or SeaMonkey) by one of the following:
- match on WebKit
- match on "like Gecko"
- for Safari: match on Safari as opposed to Firefox, SeaMonkey, etc.
(http://www.useragentstring.com/pages/Safari/)

Yes, there's extra effort involved, but in principle it should be workable, no? I guess Ben is proposing Gecko/somethingOtherThanDateSuchAsVersion, which would allow distinguishing the original Gecko w/o having to try extra matches like the above. Perhaps that idea is worth pondering a bit more, but it appears to be workable w/ just Gecko as well.
FWIW,
/ Gecko /
and
/Gecko /
regex expressions would also match the original gecko starting with Firefox 4, but not match Safari or Konqueror, for instance, both of the latter having ')' instead of the last ' ' above.
The recommended way to check for the real Gecko has always been to check for "Gecko/" so far, so if we break that, we are likely to break those checks our tech evang people have achieved to go that way, via efforts like geckoisgecko.org and others.
I don't see how you can fixed this without breaking sites.
I think Gecko/2.0 would break far fewer sites than just " Gecko " (bug 588909 comment 14).
(In reply to comment #86)
> I think Gecko/2.0 would break far fewer sites than just " Gecko "

I fully agree.
I'd be fine with 'Gecko/'. I'd also be fine with appending the major version, but I'm not sure what value that adds. (Given that we currently recommend sniffing 'rv', and we're not going to drop that, there's little point other than aesthetics.)

I'd hope that it's rare for people to match on a regex including at least one digit, but if people are aware of counterexamples, please speak up.
The value would be "adhere to RFC" (by form and meaning).
http://asg.web.cmu.edu/rfc/rfc2616.html#sec-14.43
http://asg.web.cmu.edu/rfc/rfc2616.html#sec-3.8
http://asg.web.cmu.edu/rfc/rfc2616.html#sec-2.2
From what I read, " Gecko/ " is even a *formal* violation.
" Gecko/2.0 " would be exactly as intended by the standard.
"Gecko" is permitted by RFC 2068 as a product token because the "/" and
product-version are optional. The relevant definitions:

User-Agent = "User-Agent" ":" 1*( product | comment )

product = token ["/" product-version]

token = 1*<any CHAR except CTLs or tspecials>

CHAR = <any US-ASCII character (octets 0 - 127)>

CTL = <any US-ASCII control character (octets 0 - 31) and DEL (127)>

tspecials      = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" | <"> |
"/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT

product-version = token

comment = "(" *( ctext | comment ) ")"

ctext = <any TEXT excluding "(" and ")">

As I understand it, "Gecko/" is therefore not technically permitted as it
doesn't satisfy the definition of token which requires at least 1 character.
I should have been reading 2616, but the same conclusion regarding the definitions of product, product-version and token applies.
Well, you could revisit the idea of pulling "Gecko/" into the comment string:

(Quoting bug 588909 comment #18)
> On the topic of doing "Gecko/rv:ver": actually, the script on geckoisgecko.com
> expects the version to start with "rv:" and end with ")" so the sniffer
> compatibility keeping form would be:
> Mozilla/5.0 (X11; Linux i686; Gecko/rv:2.0b4) Firefox/4.0b4

This would make the "Gecko/" sniffers as happy as the "rv:...)" ones. Note that this couldn't be outside the comment because ':' is a tspecials character.
Attachment #467573 - Flags: review?(jduell.mcbugs)
shaver did a drive-by IRL and argued that a) this kind of change is more worthy of a 5.0 alpha and b) we should not take things late in beta based on a reluctance to make further changes in 5.0. And we gain little by freezing the build date (it contains the same information as minor version, for releases). So let's retarget this for Future.
Target Milestone: --- → Future
No longer blocks: 586165
(In reply to comment #94)
> So let's retarget this for Future.

Argument in support of re-targetting:
If this bug was fixed for Firefox 4, and bug 583181 wasn't, then privacy wouldn't improve anyway.
Argument against re-targetting:
Are you serious about changing the format of User-Agent string again for Firefox 5? I'm sorry, but I can't fathom that. Late in Beta for Firefox 4 is much better, than a 2nd UA string format change for Firefox 5. Let's spell this out: as of Firefox 5 there will be 3 different mozilla UA string formats: pre-4, 4, and 5. Wouldn't it be confusing as hell, and bad for image? IMHO, it'd be better to get this bug out of the way now, and it's not too late. But i'm just a little guy...

P.S. One could probably come up w/ a law for software along the lines of Moore's law, like: Don't break backwards-compatibility more frequently than once in x years. I think x shouldn't be smaller than 4, or 5. Example: Java 5 broke backwards-compatibility 8 years after 1.0.
P.P.S. That said, i'll still support this change if it's delayed until Firefox 5, because privacy is more important than making developers struggle somewhat.
(In reply to comment #94)
> And we gain little by freezing the
> build date (it contains the same information as minor version, for releases).

Also, if we commit to delaying this until Firefox 5, freezing the buildID in UA string AND JS property makes a ton of sense: at the very least, it will increase awareness of the upcoming additional format change. "Deprecation" concept comes to mind.
I agree with comment 84; I don't particularly care what goes after the slash.
(In reply to comment #97)
> I agree with comment 84; I don't particularly care what goes after the slash.

Zimbra requires the next character after the slash to be a digit.

However, Google Web Search results get dumbed down if the token is changed to "Gecko/2.0". (But it's probably safe to expect Google to fix that pretty fast if Firefox 4.0 shipped with that.)

If the date string stays in Firefox 4 per comment 94, can it at least be frozen? Freezing it to e.g. today's date is carries no more compat risk than shipping a release today.
(In reply to comment #96)
> Also, if we commit to delaying this until Firefox 5, freezing the buildID in UA
> string AND JS property makes a ton of sense

Since Ben's suggestion of using branch date is as good as freezing[1], and JS property use-case hasn't been said to have a work-around yet, I should have written: 
... freezing or branch-dating the buildID in UA string AND _restricting access to_ JS property would make a ton of sense...

But the former w/o the latter is probably pointless.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=57555#c63
(In reply to comment #98)
> If the date string stays in Firefox 4 per comment 94, can it at least be
> frozen? Freezing it to e.g. today's date is carries no more compat risk than
> shipping a release today.

I'm really against freezing the build date. If we're going to keep using it then it should at least contain useful information. Bugzilla and support will still use it, and frankly, even if it's frozen sites will still use it which would mean that a frozen one could cause different stupid UA sniff bugs. If we have sites not correctly tracking it's updating now, then we could get sites not noticing it's not updating in the future. A freeze is not a real big help here.
(In reply to comment #95)
> Let's spell this
> out: as of Firefox 5 there will be 3 different mozilla UA string formats:
> pre-4, 4, and 5. Wouldn't it be confusing as hell, and bad for image?

If therefore nobody relied on UA string sniffing anymore then most of us could probably live with it.
Blocks: 589444
FYI for those not aware of the fixed 20100101 date currently planned for FF 4 (25 more people are following this bug than that bug, so some might not be aware): bug 591537 comment 40.
Reassigning to nobody. If anyone wants to work on this, feel free!
Assignee: dwitte → nobody
Status: ASSIGNED → NEW
How about the same thing as is done for Geolocation currently where there is a pop-up asking if you want to share your location?

So Firefox only exposes the Gecko build date in the UA string when the user has approved the request.

https://www.mozilla.com/en-US/firefox/geolocation/
But Gecko string is useless now for identification and should be removed.
It didn't provide any new or useful information, same as compilation date.

Firefox 4 = Gecko 2
Firefox 3.6 = Gecko 1.9.2
Firefox 3.5 = Gecko 1.9.1
Firefox 3 = Gecko 1.9
Firefox 2 = Gecko 1.8.1
Firefox 1.5 = Gecko 1.8
etc.
(In reply to comment #104)
> So Firefox only exposes the Gecko build date in the UA string when the user has
> approved the request.

That has been proposed elsewhere in this debate, and by itself is extreme overkill. It might be nice to have a request to the user to send general support data, including this, but not just this.

(In reply to comment #105)
> But Gecko string is useless now for identification and should be removed.
> It didn't provide any new or useful information, same as compilation date.

No. Firefox is not the only thing that uses Gecko. We try to get web sites to sniff for the Gecko version instead of the Firefox version, if they're going to sniff for anything in the UA string at all.
http://geckoisgecko.org/
Isn't this a dup of bug 649435 now?
Technically bug 649435 is a duplicate of this bug, also given that it bypasses the discussions here in this way...
This bug could be fixed by freezing the date in the UA string of all types of builds. Bug 649435 is about removing the date altogether.
Point taken, thanks.
tracking-firefox5: --- → ?
tracking-firefox6: --- → ?
Note that bug 649435 has been split into three different variants discussed in bug 651503, bug 651504, and bug 660498, all of which (with the exception of a configurable/optional version of bug 651504) would remove the date from the Gecko string and thus render this bug here effectively mood.

In line with comment #109 I was trying to set respective dependencies to these bugs but got a "circular reference" error, thus I'm just commenting.
No longer blocks: 588909
Depends on: 588909
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Whiteboard: fixed by bug 588909
Target Milestone: Future → mozilla13
No longer blocks: 572659
No longer blocks: 589444
Depends on: 589444
Depends on: 591537
Whiteboard: fixed by bug 588909 → fixed by bug 591537
Depends on: 817450
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: