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

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

What is the reason for allowing unauthorised access to deviceID anyway? And why by third-parties?



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