W3C home > Mailing lists > Public > public-media-capture@w3.org > June 2015

Re: Request for feedback: Media Capture and Streams Last Call

From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 28 Jun 2015 13:05:42 -0700
Message-ID: <CABcZeBMaKe2Q1VGRKUMNSqPCsGpt0-E-N8_1JS30vdaxV_0_rg@mail.gmail.com>
To: "Mike O'Neill" <michael.oneill@baycloud.com>
Cc: "public-privacy (W3C mailing list)" <public-privacy@w3.org>, "public-media-capture@w3.org" <public-media-capture@w3.org>
On Sun, Jun 28, 2015 at 12:34 PM, Mike O'Neill <michael.oneill@baycloud.com>
wrote:
>
> 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.
>

I don't find this particularly persuasive, since similar controls can be
provided here,
and the risk is less than with identifiers which are actually persistent
beyond cookie
clearning (e.g., canvas fingerprinting).


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


Yes, exactly that. Just like they can do with any other fingerprinting
surface. Remember
that this is only relevant if sites use this API but *don't* use cookies,
since if they do
use cookies and the lifetime of deviceId is coextensive with cookies, then
then the
"there is a cookie" indicator tells you what you need to know.



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

That seems like a totally reasonable thing to do if you're concerned about
this threat.


I have already pointed out that single origin scoping does not help with
> this. The value of fingerprinting is that it is mostly undetectable,


Active fingerprinting isn't at all undetectable. Quite the contrary.



> shooting ids across origins is a minor problem – already solved in many
> ways. To ubiquitous third-parties it is not an issue at all.
>

And again, they already do this with cookies. I don't see a material
difference.



> Zeroing out deviceId in non top level browsing contexts might work, how
> about that?


This seems like it's going to cause a lot of problems with embedded WebRTC
clients
which are likely to be a pretty common thing.

-Ekr
Received on Sunday, 28 June 2015 20:06:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:33 UTC