RE: Follow up issues from WebRTC / PING TPAC meeting

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