Re: Follow up issues from WebRTC / PING TPAC meeting

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)
2) device ids -> int handles (I especially don’t understand the claim that ints become IDs quickly, as long as the ints are recycled)
3) how device labels interact with permissions (and whether / why giving permission to a single device gives access to all device labels / ids).

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

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

Received on Friday, 18 October 2019 23:55:09 UTC