Re: Removing navigator.buildID?

[Henri Sivonen]

On Tue, Nov 1, 2016 at 10:09 AM, Chris Pearce  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.

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing navigator.buildID?

[Eric Rescorla]

On Tue, Nov 1, 2016 at 3:53 PM, Martin Thomson  wrote:

> On Tue, Nov 1, 2016 at 11:15 PM, Aryeh Gregor  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-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing navigator.buildID?

[Martin Thomson]

On Tue, Nov 1, 2016 at 11:15 PM, Aryeh Gregor  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.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing navigator.buildID?

[Gregory Szorc]

On Sat, Oct 29, 2016 at 7:21 AM, Kohei Yoshino 
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.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing navigator.buildID?

[Aryeh Gregor]

On Mon, Oct 31, 2016 at 4:00 PM, Henri Sivonen  wrote:
> On Mon, Oct 31, 2016 at 3:01 PM, Aryeh Gregor  wrote:
>> 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.

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.  :) )
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing navigator.buildID?

[Gijs Kruitbosch]

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


~ Gijs

On 01/11/2016 08:09, Chris Pearce 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?

cpearce.

On 11/1/2016 7:01 AM, Domenic Denicola wrote:

On Monday, October 31, 2016 at 10:54:11 AM UTC-4, Mike Taylor wrote:

On 10/31/16 9:16 AM, Henri Sivonen wrote:

On Oct 31, 2016 16:02, "Mike Taylor" > 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.

I think that's a good path forward.

--
Mike Taylor
Web Compat, Mozilla

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





___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing navigator.buildID?

[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.

On 11/1/2016 7:01 AM, Domenic Denicola wrote:

On Monday, October 31, 2016 at 10:54:11 AM UTC-4, Mike Taylor wrote:

On 10/31/16 9:16 AM, Henri Sivonen wrote:

On Oct 31, 2016 16:02, "Mike Taylor" > 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.

I think that's a good path forward.

--
Mike Taylor
Web Compat, Mozilla

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


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing navigator.buildID?

[Domenic Denicola]

On Monday, October 31, 2016 at 10:54:11 AM UTC-4, Mike Taylor wrote:
> On 10/31/16 9:16 AM, Henri Sivonen wrote:
> > On Oct 31, 2016 16:02, "Mike Taylor"  > > 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.
> 
> I think that's a good path forward.
> 
> -- 
> Mike Taylor
> Web Compat, Mozilla

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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing navigator.buildID?

[Mike Taylor]

On 10/31/16 9:16 AM, Henri Sivonen wrote:

On Oct 31, 2016 16:02, "Mike Taylor" > 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.


I think that's a good path forward.

--
Mike Taylor
Web Compat, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing navigator.buildID?

[Henri Sivonen]

On Oct 31, 2016 16:02, "Mike Taylor"  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.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing navigator.buildID?

[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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing navigator.buildID?

[Henri Sivonen]

On Mon, Oct 31, 2016 at 3:01 PM, Aryeh Gregor  wrote:
> On Mon, Oct 31, 2016 at 10:02 AM, Chris Peterson  
> 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
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing navigator.buildID?

[Aryeh Gregor]

On Mon, Oct 31, 2016 at 10:02 AM, Chris Peterson  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")?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing navigator.buildID?

[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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing navigator.buildID?

[Karl Dubost]

about navigator.buildID

Le 30 oct. 2016 à 18:27, Pascal Chevrel  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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing navigator.buildID?

[Pascal Chevrel]

Le 30/10/2016 à 00:34, Nicholas Alexander a écrit :

On Sat, Oct 29, 2016 at 7:21 AM, Kohei Yoshino 
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?


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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing navigator.buildID?

[Nicholas Alexander]

On Sat, Oct 29, 2016 at 7:21 AM, Kohei Yoshino 
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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform