Re: Towards a getUserMedia/enumerateDevices fingerprinting solution

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

Received on Monday, 11 February 2019 06:31:37 UTC