- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Wed, 23 Jan 2019 22:26:19 +0000
- To: public-webrtc-logs@w3.org
> what information do you provide to the user to pick the devices?
Check out [webrtc samples](https://webrtc.github.io/samples/src/content/devices/input-output/) in Safari or Firefox and you'll see "microphone 1" and "camera 1" choices.
> second visit, the app can provide labels for some devices but it cannot reliably do so in all cases
Actually, the spec says to provide labels the second time around, even though Firefox doesn't. See
[[1]](https://w3c.github.io/mediacapture-main/getusermedia.html#dom-mediadevices-enumeratedevices): *"otherwise set* list-permission *to the result of retrieving the permission state of the "device-info" permission. If* list-permission *is not "granted", let filteredList be a copy of resultList, and all its elements, where the label member is the empty string."* and
[[2]](https://w3c.github.io/permissions/#ref-for-permission-request-algorithm): *"If result is "granted", the UA MUST set the "device-info" permission to "granted" for this realm."*
But yes, In Firefox you'd choose between "FaceTime HD camera" or "camera 2". Seems fine to me.
> Given the web page took the risk of triggering a user prompt, this pattern will probably not be used for fingerprinting purposes.
It doesn't risk a prompt if you add one constraint. `OverconstrainedError` = yes, `NotFoundError` = no.
In any case, we both seem to point to equivalence with different conclusions. ;) Doesn't the fingerprinting ship sink either way? Yes *enumerateDevices()* is somewhat redundant solely to detect "has both camera and mic", unless you'd mourn early detection, which I personally wouldn't. The bigger problem on this one is backwards compatibility at this point. I'm also confused, is Safari considering returning zero devices pre-grant?
> devicechange indeed require focus but the data is buffered so that actions taken by the user before the focus might be disclosed to the page.
The page gets a single event on focus, as if it had just happened. A state event; hardly history.
> On the contrary, the history of keypress is not disclosed to the page.
Caps lock.
> devicechange event requires focus but there are workarounds to do enumerateDevices polling by calling it in an iframe and reloading the iframe every second or so.
That is something we should fix in the spec if we can. Please file an issue! Maybe [[[storedDeviceList]]](https://w3c.github.io/mediacapture-main/getusermedia.html#mediadevices) should be global. Fixing that should take care of it (no need to defer *enumerateDevices()* promise).
> If a query is crafted so that it will never trigger a prompt, it means that one constraint in the query is expected to fail 100% of the time. To not provide any information to the page, this should be the constraint to expose.
Good ideas! Though where would you draw the line? `{width: {min: 1921}}`? I vote we open a separate issue on this.
--
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/559#issuecomment-456990813 using your GitHub account
Received on Wednesday, 23 January 2019 22:26:21 UTC