Removing navigator.buildID?

[Kohei Yoshino]

So the Battery Status API has just been removed, I think now is a good time to think about navigator.buildID again, which bug [1] has been inactive for a whole year.

4 years ago, Firefox 16 removed a minor version number from the user agent string to mitigate fingerprinting [2][3]. However, the build ID unique to each minor version is still exposed via the non-standard navigator.buildID property. Since trackers can easily retrieve build IDs from Mozilla Wiki [4] to map them to minor version numbers, the fix in Firefox 16 was totally meaningless.

There were some legitimate use cases on Mozilla properties, for example, warning visitors who are using an outdated Firefox, but those usages have been replaced with the UITour API [5]. A comment in the bug [1] explains that Netflix was also using the build ID to detect a specific playback bug in Firefox, but it's probably not longer relevant. Given that, I believe the buildID property should be removed, or at least made chrome-only.

Thoughts?

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=583181
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=728831
[3] https://www.fxsitecompat.com/en-CA/docs/2012/ua-string-no-longer-contains-patch-level-version-number/
[4] https://wiki.mozilla.org/Releases/Firefox_49/Test_Plan#Milestones
[5] https://bedrock.readthedocs.io/en/latest/uitour.html

-Kohei

[Nicholas Alexander]

On Sat, Oct 29, 2016 at 7:21 AM, Kohei Yoshino <kohei....@gmail.com>
wrote:

> So the Battery Status API has just been removed, I think now is a good
> time to think about navigator.buildID again, which bug [1] has been
> inactive for a whole year.
>
> 4 years ago, Firefox 16 removed a minor version number from the user agent
> string to mitigate fingerprinting [2][3]. However, the build ID unique to
> each minor version is still exposed via the non-standard navigator.buildID
> property. Since trackers can easily retrieve build IDs from Mozilla Wiki
> [4] to map them to minor version numbers, the fix in Firefox 16 was totally
> meaningless.
>
> There were some legitimate use cases on Mozilla properties, for example,
> warning visitors who are using an outdated Firefox, but those usages have
> been replaced with the UITour API [5]. A comment in the bug [1] explains
> that Netflix was also using the build ID to detect a specific playback bug
> in Firefox, but it's probably not longer relevant. Given that, I believe
> the buildID property should be removed, or at least made chrome-only.
>

I concur, we shouldn't leak such fine-grained information about the UA to
content. For future discussion, my Nightly uses

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0)
Gecko/20100101 Firefox/52.0

but navigator.buildID is 20161015030203, revealing much more than 52.0.

As for chrome-only -- I wonder how many consumers there are.
about:support, perhaps?

Nick

[Pascal Chevrel]

Hi,

IMO the builID is important for our community of nightly testers that
report bug and need to indicate precisely in which build they found a
regression, so keeping that information available via about:support and
extensions such as Nightly Testers Tools seems valuable for mozilla to
me in a chrome context.

Regards

Pascal


--
Pascal Chevrel
pascalc on irc://irc.mozilla.org/nightly

[Karl Dubost]

about navigator.buildID

Le 30 oct. 2016 à 18:27, Pascal Chevrel <pas...@mozilla.com> a écrit :
> so keeping that information available via about:support and extensions such as Nightly Testers Tools seems valuable for mozilla to me in a chrome context.

Could it be kept without exposing it to Web content?



--
Karl Dubost, Mozilla
http://www.la-grange.net/karl/moz

[Chris Peterson]

On 10/30/2016 2:27 AM, Pascal Chevrel wrote:
> IMO the builID is important for our community of nightly testers that
> report bug and need to indicate precisely in which build they found a
> regression, so keeping that information available via about:support and
> extensions such as Nightly Testers Tools seems valuable for mozilla to
> me in a chrome context.

Limiting navigator.buildID to chrome context is a simple change: just
add the "ChromeOnly" annotation to buildID's webidl [1] and fix any
fallout like DOM test [2].

However, the Gecko Media Playback team and Netflix still use buildID
(collected by Netflix's video player JavaScript) to identify regressions
and verify bug fixes. I believe they mostly watch the Firefox Beta
channel (because there are too few Netflix customers on Nightly and Dev
Edition) to verify bug fixes. We could limit buildID to pre-release
channels, but those channels are where buildID exposes the most unique
entropy (because every day's build has a new buildID). All Firefox
Release channel users (for a given OS and Firefox dot-release) have the
same buildID.

Alternately, buildID could be hidden behind a domain whitelist pref,
seeded with sites working with Mozilla. If you are, say, a Netflix
customer, they already know who you are, so exposing your buildID to
them is not much of a tracking risk. :)


[1]
http://searchfox.org/mozilla-central/source/dom/webidl/Navigator.webidl#187
[2]
http://searchfox.org/mozilla-central/source/dom/tests/mochitest/bugs/test_bug351601.html#24

[Aryeh Gregor]

On Mon, Oct 31, 2016 at 10:02 AM, Chris Peterson <cpet...@mozilla.com> wrote:
> Alternately, buildID could be hidden behind a domain whitelist pref, seeded
> with sites working with Mozilla. If you are, say, a Netflix customer, they
> already know who you are, so exposing your buildID to them is not much of a
> tracking risk. :)

If the concern is fingerprinting, perhaps it could be exposed only to
sites that the user is logged into (assuming we have a good working
definition of "logged in")?

[Henri Sivonen]

On Mon, Oct 31, 2016 at 3:01 PM, Aryeh Gregor <a...@aryeh.name> wrote:
> On Mon, Oct 31, 2016 at 10:02 AM, Chris Peterson <cpet...@mozilla.com> wrote:

>> Alternately, buildID could be hidden behind a domain whitelist pref, seeded
>> with sites working with Mozilla. If you are, say, a Netflix customer, they
>> already know who you are, so exposing your buildID to them is not much of a
>> tracking risk. :)
>

> If the concern is fingerprinting, perhaps it could be exposed only to
> sites that the user is logged into (assuming we have a good working
> definition of "logged in")?

I think that's over-engineering it.

I suggest we make it behave the current way for chrome,
https://*.mozilla.org and https://*.netflix.com origins and make it
return a constant otherwise.

--
Henri Sivonen
hsiv...@hsivonen.fi
https://hsivonen.fi/

[Mike Taylor]

On 10/29/16 9:21 AM, Kohei Yoshino wrote:
> I think now is a good time to think about navigator.buildID again

> Thoughts?

Seems like we'd potentially end up breaking legacy sites that sniff that
to mean "isMozilla".

--
Mike Taylor
Web Compat, Mozilla

[Henri Sivonen]

On Oct 31, 2016 16:02, "Mike Taylor" <mi...@mozilla.com> wrote:
>
>
>
> On 10/29/16 9:21 AM, Kohei Yoshino wrote:
>>
>> I think now is a good time to think about navigator.buildID again
>> Thoughts?
>
>
> Seems like we'd potentially end up breaking legacy sites that sniff that
to mean "isMozilla".
>

I suggest returning a constant value to general Web sites to avoid this
problem.

[Mike Taylor]

On 10/31/16 9:16 AM, Henri Sivonen wrote:
> On Oct 31, 2016 16:02, "Mike Taylor" <mi...@mozilla.com

I think that's a good path forward.

[Domenic Denicola]

If Gecko has no plans to remove this and conform to the spec, could someone file an issue or pull request on https://github.com/whatwg/html requesting that buildID be added to Gecko compatibility mode? https://html.spec.whatwg.org/multipage/#concept-navigator-compatibility-mode

[Chris Pearce]

It's not just Netflix that the media playback team has used
navigator.buildID in order to validate fixes; we've used it with other
large video sites too. It's invaluable for determining whether a bug has
been fixed in a build. Can we only disable navigator.buildID in release
builds? Don't users on pre-release versions of Firefox update more
often, and thus the buildID changes too rapidly to be useful?

cpearce.

[Gijs Kruitbosch]

The buildID changing rapidly provides a bigger, rather than a smaller,
fingerprinting surface.

~ Gijs

[Aryeh Gregor]

This only helps us and Netflix. Other sites that want to track fixes
will be left out in the cold.

Taking a step back: is fingerprinting really a solvable problem in
practice? At this point, are there a significant fraction of users
who can't be fingerprinted pretty reliably? Inevitably, the more
features we add to the platform, the more fingerprinting surface we'll
expose. At a certain point, we might be taking away a lot of features
for the sake of trying to stop the unstoppable. (I have no idea if
this is actually true now, though. This is a genuine question. :) )

[Gregory Szorc]

On Sat, Oct 29, 2016 at 7:21 AM, Kohei Yoshino <kohei....@gmail.com>
wrote:

> So the Battery Status API has just been removed, I think now is a good
> time to think about navigator.buildID again, which bug [1] has been
> inactive for a whole year.
>
> 4 years ago, Firefox 16 removed a minor version number from the user agent
> string to mitigate fingerprinting [2][3]. However, the build ID unique to
> each minor version is still exposed via the non-standard navigator.buildID
> property. Since trackers can easily retrieve build IDs from Mozilla Wiki
> [4] to map them to minor version numbers, the fix in Firefox 16 was totally
> meaningless.
>
> There were some legitimate use cases on Mozilla properties, for example,
> warning visitors who are using an outdated Firefox, but those usages have
> been replaced with the UITour API [5]. A comment in the bug [1] explains
> that Netflix was also using the build ID to detect a specific playback bug
> in Firefox, but it's probably not longer relevant. Given that, I believe
> the buildID property should be removed, or at least made chrome-only.
>

> Thoughts?
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=583181
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=728831
> [3] https://www.fxsitecompat.com/en-CA/docs/2012/ua-string-no-lo
> nger-contains-patch-level-version-number/
> [4] https://wiki.mozilla.org/Releases/Firefox_49/Test_Plan#Milestones
> [5] https://bedrock.readthedocs.io/en/latest/uitour.html

This is buried in bug 583181, but since Mozilla only ships ~1 build per
version+platform, the buildID adds little fingerprinting potential to
binaries that Mozilla distributes. The main fingerprinting concern is
around Firefox builds not produced by Mozilla. e.g. if you compile Firefox
from source, your buildID has a good chance of being unique. There is also
an increased fingerprinting risk on channels like Nightly with lower
distribution. However, this may be offset by those channels updating daily
and not providing a stable fingerprint to anchor off of.

A compromise position might be to require a configure flag to enable
navigator.buildID (or enable it being non-static). The flag would be
disabled by default but enabled in Mozilla's distributed builds. Downstream
builders would have to explicitly enable it. We could also only enable
"real buildID" on Nightly and Aurora channels, since there appears to be
some benefit to this API there.

[Martin Thomson]

On Tue, Nov 1, 2016 at 11:15 PM, Aryeh Gregor <a...@aryeh.name> wrote:
> Taking a step back: is fingerprinting really a solvable problem in
> practice? At this point, are there a significant fraction of users
> who can't be fingerprinted pretty reliably? Inevitably, the more
> features we add to the platform, the more fingerprinting surface we'll
> expose. At a certain point, we might be taking away a lot of features
> for the sake of trying to stop the unstoppable. (I have no idea if
> this is actually true now, though. This is a genuine question. :) )

https://www.w3.org/2001/tag/doc/unsanctioned-tracking/

The conclusion: it's probably a lost cause, but we still shouldn't be
building more of these.

The more principled position is that we shouldn't have to rely on UA
sniffing (which this is) to determine what a browser can and cannot
do. That there are bugs is the main reason we have these things.

Fixing the buildID to the major version (52) plus the channel
(Nightly) would be the simplest fix without adding lots of extra
complexity.

[Eric Rescorla]

On Tue, Nov 1, 2016 at 3:53 PM, Martin Thomson <m...@mozilla.com> wrote:

> On Tue, Nov 1, 2016 at 11:15 PM, Aryeh Gregor <a...@aryeh.name> wrote:
> > Taking a step back: is fingerprinting really a solvable problem in
> > practice? At this point, are there a significant fraction of users
> > who can't be fingerprinted pretty reliably? Inevitably, the more
> > features we add to the platform, the more fingerprinting surface we'll
> > expose. At a certain point, we might be taking away a lot of features
> > for the sake of trying to stop the unstoppable. (I have no idea if
> > this is actually true now, though. This is a genuine question. :) )
>
> https://www.w3.org/2001/tag/doc/unsanctioned-tracking/
>
> The conclusion: it's probably a lost cause, but we still shouldn't be
> building more of these.
>

I'm not sure I agree with this characterization of the link above. Here's
the relevant text:

"Believes that, because combatting fingerprinting is difficult, new Web
specifications should take reasonable measures to avoid adding unneeded
fingerprinting surface area. However, added surface area should not be a
primary factor in determining whether to add a new feature."

The more principled position is that we shouldn't have to rely on UA
> sniffing (which this is) to determine what a browser can and cannot
> do. That there are bugs is the main reason we have these things.
>

I agree people shouldn't be using UA sniffing for this purpose, but it's
very useful for determining what the heck is going on when there are
inevitably bugs.

Fixing the buildID to the major version (52) plus the channel
> (Nightly) would be the simplest fix without adding lots of extra
> complexity.
>

Maybe. The nightly population is pretty small and inherently has less
privacy, and release tends to be fairly homogenous. I'd like to see
some real analysis of the privacy impact before removing a useful
diagnostic surface.

-Ekr

_______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Henri Sivonen]

On Tue, Nov 1, 2016 at 10:09 AM, Chris Pearce <cpe...@mozilla.com> wrote:
> It's not just Netflix that the media playback team has used
> navigator.buildID in order to validate fixes; we've used it with other large
> video sites too. It's invaluable for determining whether a bug has been
> fixed in a build. Can we only disable navigator.buildID in release builds?
> Don't users on pre-release versions of Firefox update more often, and thus
> the buildID changes too rapidly to be useful?

I think it's more important to freeze it on Nightly, because on the
Nightly channel fewer users at a given point in time share the same
build id than on the release channels.

While the build id changes so often that on Nightly it's not useful
for a given site doing longitudinal tracking (beyond the fact that the
user uses Nightly, which is visible from the UA string), the Nightly
build id enables rather precise correlation of Nightly user identity
across multiple sites (that include a third-party tracker) during as
browsing session.

I see that there can be value to debugging e.g. YouTube issues, but I
still think we should return a frozen value to the Web in general,
including YouTube. What makes Netflix different from YouTube is, of
course, that a) you can't use Netflix in a meaningful way without
identifying yourself via a credit card, b) Netflix content isn't
embedded on third-party sites and c) Netflix isn't (AFAIK) in the ad
business. If we think it's not OK to give Netflix special treatment on
principle, let's freeze the id altogether, including for Netflix.