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

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

>> EKr:"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."

>> Mike: "New APIs need to take into account what we have learnt
> since then and user’s increasing concerns about privacy."

I second Mike's remark. Privacy by design is a risk-based iterative 
process. Taking into account how technology is adopted and impemented 
and improving standards and protocols is a core responsability of the 
engineering community IMHO.

mvg::Rob

Mike O'Neill schreef op 2015-06-29 12:28:
> -----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-----

Received on Monday, 29 June 2015 10:38:42 UTC