Reşat SABIQ (Reshat) Reporter
	Description • 14 years ago

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; tr; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; tr; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8

Non-mozilla vendors' build dates vary, and exposing navigator.buildID to everybody makes it virtually impossible for non-Windows users to protect the private information of them using an OS used by, say, 1% of computer users. Thus it is a privacy issue.
Even for Windows users this element increases fingerprintability, which is also a privacy concern, though less so than it is for non-Windows users.

Reproducible: Always

Steps to Reproduce:
1. Access http://browserspy.dk/showprop.php or javascript:alert(navigator.buildID)


Actual Results:  
buildID  row or alert reveals build time down to the second

Expected Results:  
This information should not be revealed to every site on the web.

This was originally provided as a fix for bug 345993, but its current implementation appears to be an overkill. Testers can have access to this info w/o also revealing it to every site on the web.

general.buildID.override is available to override this property, but it is unrealistic and effectively unusable for non-Windows users to prevent being identified as members of a group of, say, 1% of computer users. 1% of users is the biggest "forest" a user of English Linux can hope to be in today. The value is likely to be even smaller for users of less powerful languages. The reason this override doesn't solve the problem:
you have to also use Windows, 
and update that installation, then determine the buildID, and then set the override on the Linux
installation, and then you have to repeat that 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 (besides, what percentage of mozilla users knows about navigator.buildID, or knows they can paste a javascript url into location bar, or are aware of a site like browserspy.dk providing that info?).

This bug could be considered dependent on 572661, because User-Agent Gecko build date has to be reformed or abolished first, otherwise it doesn't make sense to resolve this bug. At the same time, if navigator.buildID bug is resolved, any reservations about removing Gecko build date from UA string will be resolved as well, so it appears to be a 2-way relationship.

As far as testers having access to this info, some approaches suggested in prior discussions include:
1. JS API accessible over https only by mozilla certified sites (or otherwise, configurable list of sites)
2. Nightlies providing this info automatically (to everybody), but not stable releases.
3. Testers looking this up from an about: url or About dialog manually.

	Reşat SABIQ (Reshat) Reporter
	Comment 1 • 14 years ago

Also, IE doesn't expose build date, and as far as i know neither does Opera.

P.S. Since lately there has been some good progress w/ sub-set privacy bugs, rather than super-set privacy bugs, i'm logging this in addition to bug 572661. I don't care if everything gets fixed in 1 bug, as long as navigator.buildID issue is fixed as well as Gecko build date reform or abolition in User-Agent string. Chances are both fixes need to be released together, although at least theoretically they don't have to be.

	David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)
	Comment 2 • 14 years ago

Comments in bug 572661 have use cases for why we want to keep this.

	Ben Bucksch (:BenB)
	Comment 3 • 14 years ago

Specifically, bugzilla will want to keep this.
Ideas:
- Invent a way/protocol for bugzilla to query these things. E.g. before navigator.buildID returns the value, it shows a confirmation dialog to the user, or it checks a whitelist (in prefs) of sites which are allowed to query this property.
- Some new kind of protocol, specifically for bugzilla.mozilla.org and maybe the company's internal website.
Other ideas?

	rsx11m
	Comment 4 • 14 years ago

There have been comments in the other bugs arguing against a private API for "sites which may need it" due to the lack of transparency, so I would vote against the 2nd option. If you really want to go through all the effort of developing some permission system, make it a first-run dialog with the option to add that site to your whitelist or to block it permanently, otherwise the user will be annoyed with that dialog every time he/she loads that site.

	Reşat SABIQ (Reshat) Reporter
	Comment 5 • 14 years ago

I guess this could be called approach 4, in addition to 3 in comment 0.

(In reply to comment #3)
> - Invent a way/protocol for bugzilla to query these things. E.g. before
> navigator.buildID returns the value, it shows a confirmation dialog to the
> user, or it checks a whitelist (in prefs) of sites which are allowed to query
> this property.

Btw., approach 2. doesn't have the drawback of a change in UA string during testing, a drawback mentioned in bug 572661, which is another argument in favor of getting rid of buildID in UA string completely, and handling the use-case via js property...

	marginal
	Comment 6 • 14 years ago

If the only justification for this is based on a single site which coincidentally is the one you are using now, I think that is no justification.

Such sophisticated user's can easily learn to copy-and-paste this type of information when they consent to pass it on. 

It is a significant privacy invasion of which the less-sophisticated users are unaware, and the more sophisticated users, as described above, powerless to do anything about except to support this bug report.

	marginal
	Comment 7 • 14 years ago

('justification for this' meaning justification for the current malware behaviour of Firefox)

	Kohei Yoshino [:kohei]
	Comment 8 • 9 years ago

FYI: www.mozilla.org is using navigator.buildID to detect Firefox 31 ESR users (Bug 1125166, Bug 1128885). For Firefox 38, we probably don't need the property since the new mozUITour API provides the channel & minor version info (Bug 1065525), but looks like there are some edge cases where the API doesn't work, then navigator.buildID may still be our friend.

# I personally think this property should be removed for user privacy.

	dirtyridge
	Comment 9 • 9 years ago

navigator.buildID is the build time down to the second. Effectively, this _uniquely_ identifies users who build firefox from source (e.g. Gentoo Linux users). This is a major privacy issue.

	dirtyridge
	Comment 10 • 9 years ago

If this is required on a specific site, at least hardcode the property so that it is only visible on that site. Or add a config preference to disable it, at least.

	Kohei Yoshino [:kohei]
	Comment 11 • 9 years ago

As part of Bug 1216225, www.mozilla.org is removing the use of navigator.buildID. But anyway, for privacy reasons, Firefox could implement a whitelist that only allows *.mozilla.org to check the property.

	Kohei Yoshino [:kohei]
	Comment 12 • 9 years ago

Posted the site compatibility doc: https://www.fxsitecompat.com/en-US/docs/2015/navigator-buildid-will-be-removed/

	David Bruant
	Comment 13 • 9 years ago

> Firefox could implement a whitelist that only allows *.mozilla.org to check the property.

Instead of this special-casing, could *.mozilla.org read the User-Agent string (navigator.userAgent) instead of navigator.buildID? This should be enough to distinguish ESRs, no?

	Kohei Yoshino [:kohei]
	Comment 14 • 9 years ago

The UA string doesn't have any info on the Firefox channels, unfortunately. 

I have another idea here:

1. Add the build ID to the mozUITour API's appinfo payload, that currently provides the channel name and minor/patch-level version number only (See Bug 1070138)
2. Enable the API on bugzilla.mozilla.org (currently only www.mozilla.org is whitelisted, IIRC)
3. Change the Bugzilla code to utilize the API
4. Completely remove this navigator.buildID property

Thoughts?

	Chris Peterson [:cpeterson] Assignee
	Comment 15 • 9 years ago

An argument against removing navigator.buildID: Netflix has been using buildID to help the Media Playback team verify whether EME bugs are fixed in specific beta builds. buildID is not very useful for tracking release channel users because most will have the same buildID.

	Reşat SABIQ (Reshat) Reporter
	Comment 16 • 9 years ago

FYI, i have an addon that blends buildID in:
https://addons.mozilla.org/en-US/firefox/addon/blend-in/

However, whether & by how much it reduces fingerprintability depends on how much browser-identifying data (in particular using JS) a site analyzes...

	Kohei Yoshino [:kohei]
	Comment 17 • 9 years ago

Bug 728831 removed the patch level version from the UA string to reduce fingerprintability, but navigator.buildID still allows us to detect patch level differences. It doesn't make sense.

https://www.fxsitecompat.com/en-US/docs/2012/ua-string-no-longer-contains-patch-level-version-number/

	Reşat SABIQ (Reshat) Reporter
	Comment 18 • 9 years ago

(In reply to Kohei Yoshino [:kohei] from comment #17)
> Bug 728831 removed the patch level version from the UA string to reduce
> fingerprintability, but navigator.buildID still allows us to detect patch
> level differences. It doesn't make sense.
I fully agree: fingerprintability hasn't been reduced at all yet, with the exception of locale being removed from UA string, and locale displayed being Accept-Language's instead of UI's.

(In reply to Chris Peterson [:cpeterson] from comment #15)
> Netflix has been using
> buildID to help the Media Playback team verify whether EME bugs are fixed in
> specific beta builds.
IMHO, there should be a different mechanism for this type of use-case, that doesn't involve worse fingerprintability for ordinary users. E.g., beta builds could expose buildID, but stable ones not. This kinda goes along with item 2. in comment 0:

(In reply to Reşat SABIQ (Reshat) from comment #0)
> 1. JS API accessible over https only by mozilla certified sites (or otherwise, configurable list of sites)
> 2. Nightlies providing this info automatically (to everybody), but not stable releases.
> 3. Testers looking this up from an about: url or About dialog manually.

	Henri Sivonen (:hsivonen)
	Comment 19 • 9 years ago

(In reply to Chris Peterson [:cpeterson] from comment #15)
> An argument against removing navigator.buildID: Netflix has been using
> buildID to help the Media Playback team verify whether EME bugs are fixed in
> specific beta builds. buildID is not very useful for tracking release
> channel users because most will have the same buildID.

This kind of use has been very rare compared to the size of the Web. While we might have use cases to expose the build ID to mozilla.org (authenticated to be the real mozilla.org via https) or, for a limited time, to a particular site (again, authenticate via https) with which we are debugging a given API, we really shouldn't be exposing this ID to every site on the Web or even permanently to a specific non-Mozilla site.

	David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)
	Comment 20 • 9 years ago

(In reply to Reşat SABIQ (Reshat) from comment #18)
> IMHO, there should be a different mechanism for this type of use-case, that
> doesn't involve worse fingerprintability for ordinary users. E.g., beta
> builds could expose buildID, but stable ones not. This kinda goes along with
> item 2. in comment 0:

For stable builds, build ID doesn't add much (if anything) in addition to platform + version, since Mozilla only distributes one build per platform and version.

	Kohei Yoshino [:kohei]
	Comment 21 • 8 years ago

Just created a thread on the dev-platform list.
https://groups.google.com/d/topic/mozilla.dev.platform/Bg2xdgUZ_QQ/discussion

	Simon Mainey
	Comment 23 • 7 years ago

With FF56+ and privacy.resistFingerpinting => true, all test results do not leak the buildID

[1] http://browserspy.dk/useragent.php - see UserAgent from header, and User Agent from JavaScript
[2] http://browserspy.dk/browser.php - see navigator.userAgent
[3] http://browserspy.dk/showprop.php - see buildID and productSub and userAgent
[4] http://ip-check.info/?lang=en - see Browser type

FYI: if you want to close this

	Reşat SABIQ (Reshat) Reporter
	Comment 24 • 7 years ago

IMHO, IFF privacy.resistFingerpinting was true by default (as of FF 56 it's not), then this bug could be closed. As of now, it's still revealed to sites by default.

	Jonathan Watt [:jwatt]
	Comment 25 • 6 years ago

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)

	Chris Peterson [:cpeterson] Assignee
	Comment 26 • 6 years ago

(In reply to David Baron :dbaron: 🏴󠁵󠁳󠁣󠁡󠁿 ⌚UTC-7 from comment #20)
> For stable builds, build ID doesn't add much (if anything) in addition to
> platform + version, since Mozilla only distributes one build per platform
> and version.

Build ID can be used to differentiate Firefox dot releases and ESR minor versions even though their UA strings only reveal the Firefox major version. Assuming ~2 dot releases per stable release and 9+ minor versions per ESR, that's about 2 and 4 extra bits of user entropy respectively.

Build IDs for Firefox 62 dot releases on macOS:

62.0.0 = 20180830143136
62.0.2 = 20180920131237

Build IDs for Firefox ESR 60 minor versions on macOS:

60.1.0 = 20180621121604
60.2.0 = 20180903060751
60.2.1 = 20180920175354

	David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)
	Comment 27 • 6 years ago

I was assuming that dot-release version was already detectable due to web-facing changes, although perhaps that's only true for some dot releases.

	Henri Sivonen (:hsivonen)
	Comment 28 • 6 years ago

I think we should have a broader view than just Mozilla's release builds: It's bad if builds made by someone other than Mozilla stand out from the crowd for tracking purposes.

(I think we should either freeze navigator.buildID everywhere or freeze it in general but leave it as is when accessed from chrome or from https://*.mozilla.org/.)

	Tom Ritter [:tjr] (OOTO until 4/30 at least)
	Comment 29 • 6 years ago

Bug 1450398 is related to this; in that we want to add a mechanism for users to opt out of Fingerprinting Resistance on a per-origin basis.

We spoof buildid in RFP; but this bug is about restricting it generally. I think there's still some overlap with 1450398, even though it's not the same thing.

	Chris Peterson [:cpeterson] Assignee
	Comment 30 • 6 years ago

But still allow chrome and *.mozilla.org content to access navigator.buildID.

	Chris Peterson [:cpeterson] Assignee
	Comment 31 • 6 years ago

Depends on D7262

	Marco Castelluccio [:marco]
	Comment 32 • 6 years ago

Comment on attachment 9013226 [details]
Bug 583181 - Remove unused Marketplace domains from mochitest whitelist. r?marco

Marco Castelluccio [:marco] has approved the revision.

	Chris Peterson [:cpeterson] Assignee
	Comment 33 • 6 years ago

The incorrect LEGACY_BUILD_ID will be fixed in a subsequent changeset.

We must add https://www.mozilla.org/ to server-locations.txt and regenerate the mochitest certificates [1] because the new navigator.buildID test pretends to load content from https://www.mozilla.org/.

[1] https://searchfox.org/mozilla-central/source/build/pgo/certs/README

	Chris Peterson [:cpeterson] Assignee
	Comment 34 • 6 years ago

"Gecko trail" is the term used by MDN [1] for the YYYMMDD build date in the UA string's "Gecko/" token. Build ID is a YYYYMMDDHHMMSS build timestamp. Use LEGACY_BUILD_ID to spoof navigator.buildID. Use LEGACY_UA_GECKO_TRAIL to construct the UA string.

[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox

Depends on D7982

	Kohei Yoshino [:kohei]
	Comment 35 • 6 years ago

Do we really need the exception for *.mozilla.org? And, if needed, is that enough? Nowadays many Mozilla sites are not on *.mozilla.org but on *.mozilla.com (like crash-stats.mozilla.com), *.firefox.com (like screenshots.firefox.com) or other domain. See https://docs.google.com/spreadsheets/d/1Vh8lAXh7cQ5VVBW8EWu7pTA1EaNVvpVplLFGPBELRHw for more.

	Chris Peterson [:cpeterson] Assignee
	Comment 36 • 6 years ago

(In reply to Kohei Yoshino [:kohei] from comment #35)
> Do we really need the exception for *.mozilla.org? And, if needed, is that
> enough? Nowadays many Mozilla sites are not on *.mozilla.org but on
> *.mozilla.com (like crash-stats.mozilla.com), *.firefox.com (like
> screenshots.firefox.com) or other domain.

Good point about the variety of Mozilla domains in use. I would happily remove the mozilla.org exception. It complicates the code and tests.

	Pulsebot
	Comment 37 • 6 years ago

Pushed by cpeterson@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/520b22993bc4
Part 0: Remove unused Marketplace domains from mochitest whitelist. r=marco
https://hg.mozilla.org/integration/mozilla-inbound/rev/1cb48be0b5d9
Part 1: Add test for current navigator.buildID behavior. r=hsivonen
https://hg.mozilla.org/integration/mozilla-inbound/rev/a02d4b283030
Part 2: Add separate definitions for LEGACY_BUILD_ID and LEGACY_UA_GECKO_TRAIL. r=hsivonen
https://hg.mozilla.org/integration/mozilla-inbound/rev/61b6c0110dea
Part 3: Spoof navigator.buildID for web content. r=hsivonen

	Stefan Hindli [:stefan_hindli]
	Comment 38 • 6 years ago
bugherder

https://hg.mozilla.org/mozilla-central/rev/520b22993bc4
https://hg.mozilla.org/mozilla-central/rev/1cb48be0b5d9
https://hg.mozilla.org/mozilla-central/rev/a02d4b283030
https://hg.mozilla.org/mozilla-central/rev/61b6c0110dea

	Kohei Yoshino [:kohei]
	Comment 39 • 6 years ago

Updated the site compatibility note: https://www.fxsitecompat.com/en-CA/docs/2018/navigator-buildid-has-been-removed/

	Chris Mills [:cmills]
	Comment 40 • 6 years ago

Note to docs team:

I've added a note to the Fx 64 rel notes:
https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/64#APIs

The ref page and compat data will need updating when this is documented.

	Chris Mills [:cmills]
	Comment 42 • 6 years ago

I'd updated the docs to describe the new behavior:
https://developer.mozilla.org/en-US/docs/Web/API/Navigator
https://developer.mozilla.org/en-US/docs/Web/API/Navigator/buildID

And submitted a PR to update the compat data:
https://github.com/mdn/browser-compat-data/pull/3110