W3C home > Mailing lists > Public > public-media-capture-logs@w3.org > September 2016

[mediacapture-main] Polling enumerateDevices potentially being a fingerprint.

From: jan-ivar via GitHub <sysbot+gh@w3.org>
Date: Wed, 28 Sep 2016 21:36:24 +0000
To: public-media-capture-logs@w3.org
Message-ID: <issues.opened-179896828-1475098581-sysbot+gh@w3.org>
jan-ivar has just created a new issue for 
https://github.com/w3c/mediacapture-main:

== Polling enumerateDevices potentially being a fingerprint. ==
I raise this separately from 
https://github.com/w3c/mediacapture-main/issues/402#issuecomment-250270935
 where @foolip discovered this, as the problem is separate, and we may
 wish to solve one or the other or both (if possible).

This is the same problem as with the devicechange event, except not 
remedied by https://github.com/w3c/mediacapture-main/issues/333.

Polling enumerateDevices is also quite expensive, so we want to 
discourage people from polling it. One way to do that would be to 
remove any advantage over the devicechange event.

One way to solve this might be to put the same limitations on 
enumerateDevices as on the event (as I suggest in 
https://github.com/w3c/mediacapture-main/issues/402#issuecomment-250286510),
 though at the risk of people not trusting enumerateDevices. We could 
go one step further and have getUserMedia adhere to the old list of 
devices as well, that way all behavior is in sync so to speak, 
although such an illusion would shatter quickly once a USB device is 
removed, and getUserMedia fails with NotFoundError, even though 
enumerateDevices insists there is a device on the system.



Please view or discuss this issue at 
https://github.com/w3c/mediacapture-main/issues/403 using your GitHub 
account
Received on Wednesday, 28 September 2016 21:36:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:27:30 UTC