- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Wed, 23 Jan 2019 20:50:29 +0000
- To: public-webrtc-logs@w3.org
> > most (all?) WebRTC usecases/apps do not seem to require it.
>
> The "select your devices before you join" screen is common enough.
How does this work though?
enumerateDevices only provides deviceId if getUserMedia is not granted.
In case this is the first call or cookies have been flushed, what information do you provide to the user to pick the devices?
In case of a second visit, the app can provide labels for some devices but it cannot reliably do so in all cases and it cannot give camera/mic previews, which might be anyway more helpful to users than labels.
> The other major use case is figuring out whether there is a cam/mic connected before calling GUM requesting access to what is present. Arguably that is working around suboptimal behaviour (not being able to say 'give me what is there with the users consent') but changing that now...
If the web site wants to get access to camera/microphone, why do this check and not call getUserMedia directly?
getUserMedia error should allow to know whether the device setup is not good or the user denied access.
If the device setup is not good and the query was {video: {deviceId: {exact: myPreferredDeviceId}}}, the website can retry with {video: true}.
If it fails again, the web page now knows that no camera devices are available/working properly. Given the web page took the risk of triggering a user prompt, this pattern will probably not be used for fingerprinting purposes.
> The use-case is: "Sorry, you have no camera". User plugs in camera. "Oh, now you're good".
I would think that usecase to be to tied to calling getUserMedia directly after the setup is good, right?
If so, a potential workaround is to display a message to the user "please check your camera or plug one" and call getUserMedia regularly. Once setup is good enough, getUserMedia prompt will be a replacement to the "Oh, now you're good" message.
> This is also detectable by calling _getUserMedia_ repeatedly.
Wouldn't that trigger at some point a getUserMedia prompt, which would be too costly for fingerprinting?
> > we would not like to have web pages being able to know that some keys were pressed before the page got focus.
I was not very clear.
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. On the contrary, the history of keypress is not disclosed to the page.
> Again, _enumerateDevices()_ and _devicechange_ require focus for the drive-by-web.
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.
Should a user plugs in a camera to do video conferencing, any long lasting web page should be able to detect this user action and know the time and duration of the video conferencing.
There are countermeasures (only resolve enumerateDevices/getUserMedia promises when page has focus, which we should probably do) but I believe the root cause is in the exposure of private information that is not needed in the first place.
> Right, the order in which constraints must be parsed is not mandated. Whatever the order Safari uses, can be exploited to leak just as much information.
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. Also, not all constraints provide the same level of information.
In general, I think that this should be treated as implementation bugs, not as behaviors we want to keep.
> > the spec could call out some of these issues
>
> _"This error gives information about what the underlying device is not capable of producing, before the user has given any authorization to any device, and can thus be used as a fingerprinting surface._
Nice to have this note.
The spec is acknowledging the issue but does not provide guidance on how to solve it.
Since this is a fingerprint vector, the questions are:
- Why should we expose that information?
- What is the minimum level of information that should be exposed to solve the problem that we are trying to solve?
- Should these errors be sanitized if the user has not granted getUserMedia access?
--
GitHub Notification of comment by youennf
Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/559#issuecomment-456960935 using your GitHub account
Received on Wednesday, 23 January 2019 20:50:31 UTC