Re: Towards a getUserMedia/enumerateDevices fingerprinting solution

Thanks Philipp for the pointers.

I agree with Jan-Ivar that for websites that want optional audio-or-video, calling getUserMedia several times seems ok to me.
It is probably easier to understand and might be less code than going through enumerateDevices.

> On Feb 26, 2019, at 11:36 PM, Philipp Hancke <fippo@goodadvice.pages.de> wrote:
> 
> Am 07.02.19 um 19:05 schrieb youenn fablet:
>> As shown by https://www.chromestatus.com/metrics/feature/timeline/popularity/1119 <https://www.chromestatus.com/metrics/feature/timeline/popularity/1119>, enumerateDevices is probably used for fingerprinting purposes.
>> A thread started on GitHub (https://github.com/w3c/mediacapture-main/issues/559 <https://github.com/w3c/mediacapture-main/issues/559>) to tackle this issue.
> 
> I took a look at some of the less... suspicious urls in the httparchive list.
> 
> landrover.it includes
>  https://static.vee24.com/v24/veedesk/v24Embedded.js
> which has a function getCapabilities.
> This is a "live customer engagement" vendor which suggests the classic "live chat with an agent about the questions you have" use-case.
> This use-case has been pitched as one of the things WebRTC enables since the early days (https://vimeo.com/47682405 shows it at 2:40, the slide is even older).
> 
> Typically the option to have a video chat would only be shown if the user has a camera and microphone which is the reason for using enumerateDevices. Whether this use-case justifies gathering that data from *all* website visitors is probably a question for data protection agencies.

This seems like a valid use case.

Let’s note first that this specific use case is slightly out of scope of https://github.com/w3c/mediacapture-main/issues/559 <https://github.com/w3c/mediacapture-main/issues/559>
https://github.com/w3c/mediacapture-main/issues/559 <https://github.com/w3c/mediacapture-main/issues/559> is specifically about non-default setup and variation of the setup.

That said, this is indeed an issue that would be good to tackle.
Depending on how widely deployed this pattern in, different user agents might choose different trade-offs.

Let’s say this ‘live customer engagement’ is important for the web site.
Even in case where the user has no camera at a given time, the website could still advertise this UI.
That might be a convenient way to tell the user to plug-in the camera in case the user is interested in ‘live customer engagement'.
What this mitigation might prevent is some particular ‘live customer’ UI optimizations where, in case of no camera, the possibility to do video chat would eat less of user screen/attention.
For instance, a chat room to exchange text messages with a camera icon that would be green if there are cameras and gray/disabled if there is no camera.

Now, let’s say one user agent mitigation is to state that cameras/microphones are always available through enumerateDevices.
The website will propose the ‘live customer engagement’ UI.
User will click on it, getUserMedia will be called and a NotFoundError error will be returned.
Since this case may happen in real life (say user unplugs the camera), the website needs to handle that case anyway in order to provide adequate information to the user.
The user agent may even decide to stop this enumerateDevices mitigation for the lifetime of the web page.

> I couldn't think of anything edgy with dodocase.com so... its a shop for ipad covers and includes
>  https://cdn.justuno.com/mwgt_4.1.js?v=1.96
> which seems to be some conversion rate optimization tool. It uses enumerateDevices to generate fingerprinting information.
> The enumerateDevices bit is fairly simple and concatenates deviceIds and kind.

We should probably prevent that case.

> 
> \_(ʘ_ʘ)_/
>