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.

-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.
[1] Modulo restrictions on the maximum lifetime of a cookie.