- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Thu, 03 Sep 2020 10:53:32 +0000
- To: public-webrtc-logs@w3.org
> I don't see the solution as workable. Can you point to a website or a jsfiddle that is broken with this change and that we would not be able to rewrite without some big refactoring and/or different user UI? > Can you explain what value that is? enumerateDevices is widely abused by trackers on the web for several reasons: - deviceIds are persistent IDs, not always double keyed. - camera/microphone setup provides useful fingerprinting bits for identifying users. - camera/microphone setup changes can tell things about the user and user activities. As part of privacy enhancement, it was decided to limit leaking to the minimum by default. Currently, default leakage is limited to whether there are not cameras/microphones. For instance, it would be easy for a website to ask camera access once to take a picture or as part of a game. It would be bad if that website could track user setup from now on without any limitation. Capture icons will most probably deter trackers from opening even for a second capture devices to get that information. > We are only starting to explore the negatives of requiring a device to be successfully opened first; I understand this is a change of behavior and that websites might want to update to optimise their flow. I fail though to understand the hard limitations this change triggers. I actually think this change is bringing improvements outside privacy improvements. Before the change, a website would have to handle the case of new users, or users that did capture but revoked permissions, or users that did capture but cleared web site data including IDB. A website would also have to handle multiple browsers with various permission models and prompts, leading to different enumerateDevices results. This change and the proposed flow of using ideal constraints simplifies things by making the model more consistent across browsers and across user states. The proposed change and proposed usage of getUserMedia is also future proof with the in-chrome device picker for getUserMedia. -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/709#issuecomment-686409911 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 3 September 2020 10:53:34 UTC