Re: Towards a getUserMedia/enumerateDevices fingerprinting solution

> On Feb 10, 2019, at 10:38 PM, Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> wrote:
> 
> On 2019-02-11 07:31, youenn fablet wrote:
>> 
>> 
>>> 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.
> 
> Just iterating what was said when the current model was designed: Many 
> have the situation that at office (with computed docked, or connected to 
> equipment in a conference room) they have one set of devices, while when 
> traveling or working from home they have another set. The app should be 
> able to know what devices are currently connected/usable.

I agree with this use case.
I think there are ways to do that without enumerateDevices though.

If a user has a complex setup, the web app will store all the device IDs being used by a user in some kind of preference order:
The web page can then do: getUserMedia({audio: {deviceId : {exact: “myPreferredMicrophoneId”}}).
If receiving an overcontrainederror, the web page will do: getUserMedia({audio: {deviceId : {ideal: “mySecondPreferredMicrophoneId”}}).
The order between myPreferredMicrophoneId  and myPreferredMicrophoneId2 can be determined by the web page once getUserMedia is granted.

The main difference between this workflow and the enumerateDevices workflow is that getUserMedia might trigger a prompt while enumerateDevices will not with most implementations.
Regular WebRTC web sites will be ok with a prompt. Scripts doing fingerprinting will not.

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

Received on Monday, 11 February 2019 06:49:11 UTC