Re: Follow up issues from WebRTC / PING TPAC meeting

On 10/9/19 1:43 AM, Jan-Ivar Bruaroey wrote:
> 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).
>
Nit: If you hash only the label and the origin into the ID, you'll have
a hard time if someone plugs in two C920 cameras into your browser's
machine.

In Chrome, I think we include the USB ID in the hash; as long as the
camera stays attached, the ID remains, but if it is unplugged and
replugged, the ID may change.


Back to main topic: I think that once the guards against probing
(modifying overconstrained, not revealing ID in getMediaDevices() before
permission) are in place, it makes sense to recommend shortening the ID.

I don't think that language should be normative at this stage, since I
don't think these guards are in place.


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