Re: Follow up issues from WebRTC / PING TPAC meeting

Hi Pete,

Thanks for following up and for the discussions we had at TPAC, this was really useful.
I think we made great progress and am confident we can update the specs accordingly.
Please see inline for some comments/precisions/questions.

 Y

> On 27 Sep 2019, at 10:36, Pete Snyder <psnyder@brave.com> wrote:
> 
> 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.

This is true if device-info permission is not granted to the page.
If device-info permission is granted (after user granted access to the camera for instance), enumerateDevices will provide the full list of devices, with labels and ids.

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

Correct.

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

I think the idea is that for browsers exposing speakers through enumerateDevices, device IDs will be double keyed.
There is discussion to find an alternative to that approach, hopefully I’ll have a full proposal soon.

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

There is consensus to remove the ‘vpn’ value.
There is strong interest to remove this value from the dictionary.

The WebRTC WG plans to gather feedback from WebRTC stats users.
Another approach that was considered is to gate this value based on some permission, though it is unclear how this would actually work.

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

The issue is not really that users will be reprompted.
Websites will not be able to setup the call configuration as done the last time if last call happened in a different top level origin.
This creates a compat risk for WebRTC SDK vendors without getting much privacy benefits if other storages are not double keyed.

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

If double keying for other storage is not shipped in some browsers, cross-site tracking will continue whatever we do about device IDs.
Note also that the WG decided that device IDs will not be accessible until capture permission is granted.
This can be shipped much sooner and will make actual usage of device IDs for tracking purposes much harder.

> 3) sites don’t “break", the embedded frame will just re-pompt the user for device access

Not really, see above.

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

I am not sure to follow, could you elaborate?


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

To pursue this approach, a more detailed proposal would be good to have.
My understanding is that either we expose some cross-site tracking information or we loose the ability for websites to configure a call persistently.

I am unclear whether the PING WG would like us to continue digging in this approach given the plan is to mandate double keying.
Can you clarify this?

As of why I am not sure how the proposal works, let’s take an example.
Say we start with two cameras (back and front) that we give 1 and 2 as device IDs. Everything is fine.
Let’s say now that a new camera is being plugged in.
We give it device ID 3.
Let’s say now that another new camera is being plugged in.
We give it device ID 4.

Now, we want persistency so that web pages can say 'I want device 3 at next visit’.
This should be working except if user clears website data like cookies for that particular website.
But we can no longer clear device IDs for this particular website since this will affect all websites.

Also, if next time, we only have device IDs 1, 2 and 4, this information will be available to all origins that have device info permission.
This would leak some interesting cross-site tracking information.
We could then decide to use 1, 2 and 3 instead but then the web site is unable to select persistently device 4.

AIUI, the double-keyed proposal solve this issue and is easier to implement by browser engines.

FWIW, I like fixed device IDs and am advocating for using some for output speakers.
This should in particular work great for devices that are always there for a given device (say loudspeaker/earpiece).

> 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 09:37:00 UTC