Build date frozen in UA string for SM 2.14.1 and later

[rsx11m]

BTW totally agree with this comment (... Hm, strange, 15 is mentioned only three times, that's may be not enough!)

The next step will likely be removal of the "rv:15.0" string which has been made redundant in this way, but they apparently want to take it piece by piece rather than breaking everything at once, thus giving web-site developers a chance to adjust first (and to adjust Mozilla's documentation and recommendations as well) before adding yet another brick. On the other hand, without really having a concept what the UA string is supposed to look like in the end, the reluctance of web sites to adopt those incremental changes is understandable.

[James]

Just bleeping replace the second 15 with the build date again. Problem solved.

[-Px-]

Just bleeping replace the second 15 with the build date again.

After each nightly update?

[therube]

From: viewtopic.php?f=40&t=2466329

I'm using nightly builds

... OK, so I'll just look at your UA & see just which nightly ...

Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/15.0 Firefox/15.0a1 SeaMonkey/2.12a1

BUT, there's no frickin build date in the UA!

WHAT MORONS!

Two steps back for every step forward.

[James]

Just bleeping replace the second 15 with the build date again.

After each nightly update?

I could do that again or hope Mozilla comes to their senses and put the build ID date back once again and keep it that way.

[rsx11m]

Maybe someone comes up with an extension to show Gecko/<date> again as obtained from the buildID?

[rsx11m]

Not quite unexpectedly, the patch to also remove the patch level from the Firefox token has been approved as well, which now makes it "Gecko/15.0 Firefox/15.0a1 SeaMonkey/2.12a1" (and remember that there is still bug 728952 to do the same with the SeaMonkey token).

[James]

Then sites and people will mistakenly think it was a Firefox 15.0 release and not a unstable Nightly. They used to have the Minefield name for the Trunk before so people would be aware it is not even close to being a release. Then they change it back to Firefox and now they want to remove the a1...

[rsx11m]

All in the name of privacy and perceived security by not exposing weak but identifying information. The arguments in favor of not further mutilating the UA string have all been brought forward and were subsequently dismissed by a small but vocal group of developers pushing forward for these reductions in UA-provided information... All you need is some exotic plug-in and you're fully fingerprintable anyway, the UA is just a single component for that purpose (and unlikely the most important one).

[rsx11m]

The recent discussion in bug 588909 makes me wonder who is actually in charge over there. This may or may not be backed out again, and then some time may land again, and then - whatever...

[Philip Chee]

The recent discussion in bug 588909 makes me wonder who is actually in charge over there. This may or may not be backed out again, and then some time may land again, and then - whatever...

Here's what I think needs to happen before relanding:

1) Use contacts at Google and Zimbra to fix problems on their end and estimate time to widely deploy. (Zimbra is of lesser importance if bug 572659 is an acceptable workaround).

2) Get to a shared understanding with Firefox module owner/peers (that's me!) and product / release drivers regarding:
* What the cost of this change is (ie, what breaks)
* What the benefit of this change is (ergo, can discuss cost/benefit)
* Plan and action for disabling on aurora/beta/release, and when we expect to
be able to leave it on through release.

Did I miss a discussion on point #2? As far as I can tell neither I, Gavin, nor Asa was aware this was was going to reland. Let alone the other points.

We currently don't seem to face a cost, and based on the gathered data and experience on mobile, there's a good chance that there's no significant yet-unknown cost.

You do not have the necessary data to support assertions of no cost. This will break sites. This will cost us users.

Until someone can make an effective case, to the Firefox Product and Module owners, that there's some significant win for users or the Web, this change should be put on hold.

This change needs to be backed out and not re-landed without support from the Firefox Product and Module owners.

Looks like users are going to be inflicted with fallout from an internal ding dong political battle.

Phil

[therube]

> Because you paste in the url from about:buildconfig?

And that's ridiculous too.
Almost to the extent of (OK not anywhere near) removing the version number from Help | About.

Many bugzilla posts post no (browser) identifying information at all.
Of those that do, in most cases, Help | About is what gets posted.
Only for those who know how to interpret & work with or need the specific build information would go to about:buildconfig.

And in any forum that sniffs the UA, like here, having a build date is always important to know.
2009 .

[rsx11m]

Actually, Firefox froze it to 20100101 (not 2009), and as far as I know they are the only ones (not counting Fennec) who froze it. Typically, they assume that if it's not important for Firefox it's not of concern for anybody else.

The discussion build ID vs. changeset ID was also presented in bug 589444 asking to add the Build ID to Toolkit's about:support implementation. Interestingly, the same people pushing to remove the date string from the UA argue against adding it to the support dialog in turn at least. What's that paranoia towards the build date good for?

BTW: about:buildconfig shows the mozilla-central changeset for me, but not the comm-central one.

[rsx11m]

Two more (SM-specific) bugs related to this discussion:

• Bug 752797 Build ID absent from about: page (no longer seen in UA string now);
• Bug 752333 Share Thunderbird's about:support implementation with SeaMonkey (which would also provide the Build ID again).

[James]

Robert Kaiser (:kairo ...)

(In reply to Tony Mechelynck [:tonymec] from comment #125)
> Now that this bug has landed, there is no build date in the About: dialog

That's a SeaMonkey bug and should be reported and fixed as such. It might be a good idea to fix it in both the generic and the SeaMonkey about: pages but in the end, it's a separate bug from this one here, it's been a bug for a while that the Gecko date in the UA string even showed a moving date, it really should have been frozen everywhere for fingerprinting reasons.

The build ID date in UA has been a bug and not a feature all this time ???