Re: Follow up issues from WebRTC / PING TPAC meeting

Here is a summary of my understanding of the discussions.
WG members, please correct me if I am wrong.

> On 19 Oct 2019, at 01:55, Pete Snyder <psnyder@brave.com> wrote:
> 
> Hi Folks,
> 
> I wanted to pick this thread up again.  Is it possible for the WG to summarize where things stand, regarding the three PING issues discussed at TPAC.  At the time it seemed like there was consensus, and that the consensus dissipated right after through the above convo, so would greatly appreciate an understanding of where things stand.
> 
> Specifically:
> 1) double keying of IDs (and how to maintain privacy protections with dynamic / overlapping privacy storage epochs like those in Safari and Brave, possibly elsewhere)

There is consensus to double key device IDs if other storage like IDB are double keyed.
There is interest within the WG in having browsers to support full double key storage. 
There is little interest within the WG in mandating browsers to double key device IDs if other storage like IDB is not double keyed.
This is in terms of implementation.

In terms of specification, my personal opinion is that it is fine to describe where browsers want to go, not where browsers are right now.
I am thus fine mandating double keying once we have proper support in the HTML spec for getting the storage partition key.
The HTML spec bits are being worked on.

> 2) device ids -> int handles (I especially don’t understand the claim that ints become IDs quickly, as long as the ints are recycled)

There is no consensus there, partly due to the fact that details are fuzzy (what means recycling in particular), also since double keying solves the same issue.

> 3) how device labels interact with permissions (and whether / why giving permission to a single device gives access to all device labels / ids).

The spec does not mandate to expose all devices after giving access to a single device.
The spec does not mandate to expose only the exposed devices.
My understanding is that the current state there is ok with the WG and that changing implementations is difficult in terms of web compatibility.

> 
> Would it be possible for the WG to summarize the current state of things, and where things have changed since the conversation at TPAC?

Stronger enumerateDevices filtering is being worked on (see https://github.com/w3c/mediacapture-main/pull/632 <https://github.com/w3c/mediacapture-main/pull/632>).
Once there is agreement there, the next steps to discuss in that area will be:
- Discuss whether we can replace device-info permission by a browsing context state.
- Discuss whether we can fully conceal the presence/absence of capture devices.

Hope this helps, let’s continue the discussion.

Thanks,
 Y

> 
> Thanks!
> 
> 
> 
> Pete Snyder
> {pes,psnyder}@brave.com
> Brave Software
> Privacy Researcher
> 
>> On Oct 10, 2019, at 3:44 AM, Mike O'Neill <michael.oneill@baycloud.com> wrote:
>> 
>>>> Pretty sure revoking camera and microphone permissions revokes device-info permission in all browsers: https://jsfiddle.net/jib1/LbtxeLvw/show
>> Not on Chrome, Chromium Edge or Firefox
>> 
>> 
>> 
>> 
>> 
>> From: Jan-Ivar Bruaroey <jib@mozilla.com> 
>> Sent: 09 October 2019 00:43
>> To: Youenn Fablet <youenn@apple.com>
>> Cc: michael.oneill@baycloud.com; Pete Snyder <psnyder@brave.com>; public-privacy <public-privacy@w3.org>; public-webrtc@w3.org
>> Subject: Re: Follow up issues from WebRTC / PING TPAC meeting
>> 
>> On 10/7/19 2:48 AM, Youenn Fablet wrote:
>> 
>>>> The remaining discussion appears to be what's shared once this implicit device-info permission is granted, which is lots of stuff. Like labels.
>>> It seems part of the issue comes from the fact that browsers may decide to grant the device-info permission forever after a getUserMedia prompt is granted once.
>>> This might be difficult for users to remember and understand.
>> Sorry I meant to focus on the deviceId still. I aimed to show that—assuming we follow the parts of Safari's model we agree on—the deviceId is not exposed until the label is exposed. That they both leak when the device-info permission is granted is kind of irrelevant, since neither the id nor the label (e.g. "HD PRO Webcam C920") expire on revocation of the device-info permission. By that I mean they're already leaked and presumably stashed in storage.
>> To stress my point: double-keying the deviceId seems silly when you have the label of which it is a hash (+ origin).
>> Sure, if you don't have storage then the label goes away with the device-permission (it disappears from future enumerateDevices() calls).
>>> This behaviour is in user agent land and the spec does not say anything about it right now. Maybe the spec should provide guidelines and warn against that.
>> Pretty sure revoking camera and microphone permissions revokes device-info permission in all browsers: https://jsfiddle.net/jib1/LbtxeLvw/show
>>> Or we could go further and only expose device info on a page based on specific user actions on that page, like if getUserMedia promise is resolved successfully.
>>> Maybe we should remove the concept of the device-info permission, which is different and more difficult to explain than a camera permission or a geolocation permission.
>> This is effectively what Firefox implements by default. 
>>>> Which leads me to my last idea:
>>>>  • Remove deviceId
>>>>  • Add a deviceName constraint (no-op without device-info permission)
>>>> Then let JS store the label instead:
>>>>  const stream = await navigator.mediaDevices.getUserMedia({video: {deviceName: localStorage.chosenCamera}});
>>>>  localStorage.chosenCamera = stream.getVideoTracks()[0].label;
>>>> We only needed deviceId in the first place to cover the "choose camera beforehand" use-case, when there's no label.
>>>> Would that make us happy?
>>> 
>>> In a perfect world, I am not sure we would like to expose all device labels.
>>> Labels are very persistent and, except for built-in capture devices, might be very user specific.
>>> On the contrary, the browser is in full control of device Ids, can regenerate them at will.
>>> Device IDs can also handle complex cases that labels cannot.
>> I agree with this. While I meant it as a genuine proposal (getting rid of deviceId would let us rip out a bunch of code, and close some outstanding issues to boot), I also meant to show the diminishing returns of getting rid of or trying to taper deviceId exposure alone.
>> .: Jan-Ivar :. 
>> 
> 
>