From: Eric Rescorla [mailto:ekr@rtfm.com]
Sent: 28 June 2015 18:56
To: Mike O'Neill
Cc: Greg Norcie; public-privacy (W3C mailing list); Simon Rice; public-media-capture@w3.org
Subject: Re: Request for feedback: Media Capture and Streams Last Call
On Sun, Jun 28, 2015 at 4:26 AM, Mike O'Neill <michael.oneill@baycloud.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In the last Privacy IG call I pointed out a privacy issue in Media Capture (http://www.w3.org/TR/2015/WD-mediacapture-streams-20150414/#access-control-model) .
This is where a MediaDeviceInfo object with the deviceId property is returned without any authorisation. The value returned is effectively a UID cookie singling-out the device (and obviously therefore the individual using it). This creates the possibility to easily fingerprint any user agent that supports the API.
To say the privacy risk of this is alleviated because of the same origin policy is disingenuous, as this is equivalent to placing a user unique random number i.e. a UID cookie with an infinite persistence, and of course it will be used for tracking.
It is irrelevant that the value is scoped to a single origin because any embedded third-party in their own origin iframe will be able to identify the user and even pass the identifier server-side or via the many cross-site scripting methods to the top level browsing context or to other third-parties.
Even though the identifier is reset when cookies are cleared, it should not be a requirement on users that, in order the protect their fundamental right to privacy, they have to in perpetuity periodically scrub all their cookies, some of which they may have consented to, indicate a tracking “opt-out” or that do not have a privacy impact.
I'm having trouble following your argument here.
In general, sites which can access this API can also set cookies and/or write data
to indexeddb (modulo third-party cookie blocking [0]) which allows them to equally
well track the user. And since they can put either random data or data of their own
choice there, it seems that this API is strictly less powerful than cookies [1]. Given that,
I'm not sure why you think it represents an incremental threat to user privacy.
I don't think it's really that useful to characterize this as "fingerprinting", since the
typical value proposition of fingerprinting is opposed to cookies is that it provides
a stable identifier across origins, which deviceId does not.
Tracking via cookies is relatively understood by users, user-agents or extensions making them more or less transparent. There are various ways to see what cookies have been placed, by whom, how long they will persist etc. There are now often ways for users to have fine granular control of them, again often built into browsers or if not available via extension tools. The privacy risk is still there but users at least have been given some ability to see what is happening and take some control.
The ability to fingerprint users via an always accessible UID is invisible and no existing browsers or tools help users to be aware of it. Should there be yet another browser UI to indicate “such-and-such origin has executed enumerateDevices, watch out you may be being tracked”. How will that be explained to users who are increasingly concerned about being tracked without their knowledge? The predictable result of all this will be content blocking of any third-party that executes the API (without consent if that is detectable, in any case if not).
Of course other APIs also have been released that expose fingerprinting risks, but that is no reason to add to the chaos. Every time a new API is introduced that enables invisible tracking people’s trust in the web is diminished. This will also lead to widespread blocking of third-party behaviour e.g. any third-party iframe that executes XHR or creates a beacon, a ridiculous arms race that is no good for anyone.
I have already pointed out that single origin scoping does not help with this. The value of fingerprinting is that it is mostly undetectable, shooting ids across origins is a minor problem – already solved in many ways. To ubiquitous third-parties it is not an issue at all.
-Ekr
[0] I don't know how implementations presently behave in the face of third-party
cookie blocking, but I wouldn't be averse to requiring some sort of comparable
behavior for deviceId.
Zeroing out deviceId in non top level browsing contexts might work, how about that?
[1] Modulo restrictions on the maximum lifetime of a cookie.