- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Thu, 24 Jan 2019 05:07:43 +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.
I do not see that being used in widely used websites.
In those websites, I see getUserMedia being called upfront and previews of camera to help the user select the right device.
That does not preclude to implement that UI without enumerateDevices: detect the device type based on the user agent and other available information, then fill the UI with the default cameras/microphones found for these device type. This has the advantage to gather labels using some web database even if the user never granted access to any device.
Sure, you do not have non default devices but these are not that often.
> Actually, the spec says to provide labels the second time around, even though Firefox doesn't. See
This makes state b) even more dangerous.
Say you grant access to camera access once on a website.
Now, if I understand correctly, it will get access to all device labels, not only the ones that were exposed once. This should be prevented.
> It doesn't risk a prompt if you add one constraint. `OverconstrainedError` = yes, `NotFoundError` = no.
Sure and that seems like a bad pattern.
> In any case, we both seem to point to equivalence with different conclusions. ;) Doesn't the fingerprinting ship sink either way?
I guess we agree that we disagree :)
I do not think the fingerprinting battle is lost in getUserMedia land.
I believe getUserMedia spec can be implemented modulo web compatible adjustments to prevent fingerprinting. I would prefer to be able to implement the getUserMedia spec without these adjustments. I would find it even better if the getUserMedia spec would encourage developers to do so.
> Yes _enumerateDevices()_ is somewhat redundant solely to detect "has both camera and mic", unless you'd mourn early detection, which I personally wouldn't.
Given the consequences of early detection and the currently identified use cases, I think it is reasonable to limit the power of early detection.
If you do getUserMedia({audio: true, video: true}) and you get an error that is not NotAllowedError, you actually get the information that camera and mic are not available.
> The bigger problem on this one is backwards compatibility at this point. I'm also confused, is Safari considering returning zero devices pre-grant?
Agreed that backward compatibility is an issue.
Currently, Safari rule is basically to return one microphone/one camera for Macs and one mic/two cameras for mobile (hence the empty device IDs issue). We are considering to always return one microphone and one camera no matter the exact Mac/mobile. We could go to zero devices pre-grant but there is little gain here except implementation purity.
> 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).
I filed https://github.com/w3c/mediacapture-main/issues/561.
FWIW, that is not easily fixable. There are easy workarounds if you make it process wide global.
You could make it browser global, but that will add quite a bit of complexity. Since this is scoped by origin, it will be possible to load iframes with origins 1.evil.com, 2.evil.com... with a small network cost.
Not exposing information seems like a simpler and more reliable model.
> > 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.
Filed https://github.com/w3c/mediacapture-main/issues/562
As of {width: {min:1921}}, this case is fine to me if used alone.
In 99% of the cases, this request will fail.
In 1% of the cases, a prompt will be presented to users who will probably find it scary. Users will close the tab and never come back to this website.
My preference would be to not expose any constraint name if getUserMedia is not pre-granted.
--
GitHub Notification of comment by youennf
Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/559#issuecomment-457068686 using your GitHub account
Received on Thursday, 24 January 2019 05:07:44 UTC