RE: Follow up issues from WebRTC / PING TPAC meeting

Pete, 

I think the main privacy issue is that the UID is invisible (the user has no way to see it has been accessed) and immortal (on Chromium based UAs the only way to reset it is to delete all cookies).

Double-keying makes it harder to correlate individual browsers cross-domain (because iframes on different sites get different results), but there are other way to correlate anyway e.g. cookie synching via dynamic urls, IP source address matching etc.
(double-keying all storage would be a major step forward for privacy though).

Safari makes the deviceId null on MACs and that does not seem to have caused much of a problem.

BTW for those not on the Slack here is a demo of the UID https://mediastreamuid.azurewebsites.net

Mike


-----Original Message-----
From: Pete Snyder <psnyder@brave.com> 
Sent: 27 September 2019 10:13
To: public-privacy <public-privacy@w3.org>
Cc: public-webrtc@w3.org
Subject: Re: Follow up issues from WebRTC / PING TPAC meeting

(Apologies for the double post for WebRTC folks; also cross posting to the PING list)

(Unquoted message begins below)
—-

Hello WebRTC mailing list folks,

I wanted to surface a conversation that’s been going regarding the three privacy issues discussed at TPAC w/ PING members.

As recap, this was a summary I sent, regarding PING’s understanding of the conclusions from the TPAC conversation.

> Regarding values returned by enumerateDevices (#612)
> ---
> The standard will be changed so that implementers MUST return an object that does not include any device ids or labels, one entry describing every possible device type (e.g. requesting web pages will see the exact same response object on all platforms, on all hardware, etc).  This is true regardless of the permissions granted to the page.
> 
> Regarding uniqueness of device IDs (#607)
> ---
> For existing hardware types: device IDs MUST BE double keyed (e.g. frame pointing to origin example.comwill always see a different, independent set of device IDs, for each top level frame), regardless of whether the client double-keys other storage types
> 
> For new hardware types (e.g. external speakers): device IDs MUST NOT be globally unique, but opaque-identifying integers (or some other non-identifying, non-unique handle).
> 
> Regarding "network type" identifiers in returned stats (#374)
> ---
> The standard will be updated to to remove this value from the returned dictionary of stats returned (e.g. no type key, and no "wifi", "ethernet", "vpn" value).


To prevent this email from getting too long, I’m going to try and summarize the conversation thats happened since, and then reply to the points. Doing my best to be concise but accurate in reflecting others’ opinions.  If I get something wrong, apologies, errors of ignorance, not maliciousness :)

Re double-keying device ids
---
Some WebRTC folks thinks that double-keying device ids (regardless of whether storage is double keyed) is inappropriate bc it will cause users to be re-prompted for access to the same device in cases where the same WebRT-using-site is a third party on two ore more  different 1p frames, since sites may store deviceIds in storage, and they’ll see the same storage, but diff device ids.

My view (and I believe the PING view) is that
1) Agreed tat double keying storage and device IDs is a better solution
2) since most browsers won’t be shipping double-keyed storage in the short to medium term, double-keying is not a solution to the privacy risk
3) sites don’t “break", the embedded frame will just re-pompt the user for device access
4) the current spec text of “device ids should be reset when storage is reset” does not address the privacy concern, especially as some browsers move to dynamic policies for handling JS set storage (e.g. there is no single global “storage clear” event to decide when to reset device Ids against, but lots of small micro, per value decisions)


Re move from UUID -> int counters for device ids
---
An alternate proposal PING made was to not have user identifying device ids.  This would seem to have all the privacy properties (sites can’t use device ids to track users) w/o webcompat issues, at the cost of (slight?) increased implementation complexity.

It would be good to hear if there are any anticipated web-comapt issues from this proposal.  FWIW, as context, there was unanimous agreement on PING (including by many members of this WG) that “it is grounds to formally oppose a standard if there is a more privacy preserving alternative, all other things being equal functionality wise (e.g. implementation complexity is not a reason to stick with the less private option)”.  

Given the above, I would be very grateful if folks could share web-compat or capability concern with this proposal, if there are such concerns, since it seems like a way to completely side step the double-keying-issue.


Thanks ya’ll,
Pete

Received on Friday, 27 September 2019 10:33:40 UTC