W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > January 2019

Re: [mediacapture-main] Spec does no handle fingerprinting related to exposing non default capture devices (#559)

From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
Date: Thu, 24 Jan 2019 19:03:16 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-457316839-1548356595-sysbot+gh@w3.org>
> Pre-first-grant:

I think fixing https://github.com/w3c/mediacapture-main/issues/562 for this case is reasonable. The rest of this post is about the *pre-subsequent-grant* case, because you specifically mentioned not wanting to implement (b) earlier.

I assume we're only talking about cross-site fingerprints, because:
```js
localStorage.fingerprint = Math.random().toString(36);
```
.. and if user clears cookies [1] then go to "Pre-first-grant". Otherwise:

> > Pre-subsequent-grant:
> > ...
> > 3. 99% of the time, enumerateDevices() leaks no more than getUserMedia() probing.

Here, I should have written:

 3. 99% of the time, enumerateDevices() leaks no more than JS already knows through cookies.

...since most users probably rarely change their config. For them, JS already has a reliable cross-site fingerprint: Labels of all cameras, as well as all capabilities of cameras used.

I agree this fingerprint is unreliable for a (small) sub-population who might plug/unplug USB cameras occasionally, and that sites might use *enumerateDevices()* to update this fingerprint for this sub-population from working some of the time, to all of the time. I also agree that, these configs being rare, their fingerprinting value is higher.

Do I have the value-add right?

[[1]](https://w3c.github.io/permissions/#dom-permissionname-device-info): *"The "device-info" permission MUST be revoked when deviceIds for an origin are reset. "*

-- 
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/559#issuecomment-457316839 using your GitHub account
Received on Thursday, 24 January 2019 19:03:31 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:46 UTC