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

Jumping in to the discussion …

As foreshadowed with Stefan and Dom, PING discussed: 

http://www.w3.org/TR/2015/WD-mediacapture-streams-20150414/#privacy-and-security-considerations


on our last call (Thursday 25 June 2015). We are aware that this falls after last call, but the timeframe was too short for PING members.

Mike has already raised some concerns he expressed during the call. Ekr, thank you for your responses.

What we would like to do is to consolidate the questions/perspectives from PING and share them with you (Media Capture Task Force).

Please expect a short email from us in the next day or so.

PING co-chair, Christine

> On 29 Jun 2015, at 12:38 pm, Rob van Eijk <rob@blaeu.com> wrote:
> 
>>> 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 14:48:41 UTC