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:
>>
>>  1. Remove deviceId
>>  2. 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 :.