Re: Towards a getUserMedia/enumerateDevices fingerprinting solution

Am 11.02.19 um 07:31 schrieb youenn fablet:
> 
> 
>> On Feb 10, 2019, at 11:22 AM, Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> wrote:
>>
>> On 2019-02-10 16:49, Harald Alvestrand wrote:
>>>> 1. It is assumed that:
>>>> - Leaking any fingerprinting information silently through
>>>> enumerateDevices is an issue.
>>> I am not certain there's any consensus here. The WG, when designing this
>>> iteration of enumerateDevices, has formerly decided that leaking:
>>>
>>> a) whether or not camera and/or microphone is present
>>> b) the number of audio and video devices present
>>> c) whether these devices are the same as when the page was previously
>>> granted access to them (aka "device ID is stable")
>>>
>>> is an acceptable amount of leakage.
>>>
>> Just to confirm: what Harald says above matches my recollection. And
>> there was a lot of input on that being able to pick the devices the user
>> ended up preferring last time is needed to build user friendly applications.
> 
> This use case is certainly valid.
> That said, it does not require the current information leakage that the spec is mandating, nor the use of enumerateDevices.
> One can implement it by doing the following:
> 1. A web page checks for deviceId from IDB/local storage/cookies...
> 2. If there is no deviceId, getUserMedia can be called without any constraint. On success, track.getSettings().deviceId gives the device ID and the web page stores it.
> 3. If there is a stored deviceId,  getUserMedia(audio: {deviceId: ‘lastAudioDeviceID’}, video: {deviceId: ‘lastVideoDeviceID’}}  can be used.
> Some web sites seem to follow that pattern.
> 
> Note that exposing deviceId is not even needed for this particular use case.
> The browser could be mandated to remember which device was last used so that getUserMedia({audio: true, video: true}) would be all that is need from web applications.
> 
> 

There is a more basic use-case: what arguments should you use in the 
getUserMedia call? Simply calling
   getUserMedia({audio: true, video: true})

will result in NotFoundError if either camera or microphone are not 
present. Using enumerateDevices before to determine if a camera and/or 
microphone are available is "better" than handling NotFoundError in a 
trial-and-error manner. It also avoids two permission prompts which 
would result from parallel GUM calls with just audio or video.

Chrome used to give a best-effort result (i.e. no video track on the 
resulting stream if there is no camera) but that turned out to have 
other implications because it invalidated the reasonable assumption that 
you get a video track when you ask for it or an error.

Received on Wednesday, 27 February 2019 06:33:41 UTC