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

On Mon, Jun 29, 2015 at 3:28 AM, Mike O'Neill <michael.oneill@baycloud.com>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Rules about cookies were laid down at a time the privacy risks were not as
> clear. New APIs need to take into account what we have learnt since then
> and user’s increasing concerns about privacy. Of course you could add
> sections calling for UA UI to explain the risks, which would have to be
> spelled out as it is a new technology, but why not do better than that. The
> W3C has a responsibility to regain user’s trust in the platform.
>

That's certainly not an unreasonable view, but the countervailing view is
that the limits
for what new technologies can do are set based on what the platform can
already
do with existing technologies (cf. CORS).



> What is the reason for allowing unauthorised access to deviceID anyway?


Dialog fatigue.



> And why by third-parties?


To allow embedded video calling apps.

-Ekr


>
>
> From: Eric Rescorla [mailto:ekr@rtfm.com]
> Sent: 28 June 2015 21:06
> To: Mike O'Neill
> Cc: public-privacy (W3C mailing list); public-media-capture@w3.org
> Subject: Re: Request for feedback: Media Capture and Streams Last Call
>
>
>
> 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
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using gpg4o v3.4.103.5490 - http://www.gpg4o.com/
> Charset: utf-8
>
> iQEcBAEBAgAGBQJVkR2vAAoJEHMxUy4uXm2JwzYIAJEqlSOZiJ+zJU7hMY7T5Aj+
> eW6exhWrsL/TVcY0zR2yfKp0s81XXoX3C/foFxOXUwGpg3rX23dyBa+W8nUvW4fn
> OR3lZ0Nn+cdHpl0uDO6DVfcynm8PPypTyO2snyFzVmt8pukUBJdVr00K3B4VedkG
> i+ldasgWXr4h2zcrXJltYUnQ5G8nHmPjL25uTKgpJn1lRke7EeyJSU/bgyJfP6zi
> Uo8FKdlbIBuTFHLuNlp6Rq7x5rS2yP2Fjclu7+h5VrTXyoDbcCj+QBWytACoNaoc
> KWWFGYMMR+zzjD4LP7nT9oaaz6qzBxmEFaogr0pMH9DDaC/2Y3V++gpfWC/fdGM=
> =VDdl
> -----END PGP SIGNATURE-----
>