- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Fri, 22 Nov 2024 09:58:03 +0000
- To: public-webrtc-logs@w3.org
FWIW, I do not think we can go back and weaken the privacy story. We can be creative in ways that keep the same level of privacy but mitigate breakage. Interventions are also fine to make progress. @guidou, have you considered these possibilities? To make progress on mitigations, it would be good to qualify a few things: 1. Which websites get broken 2. How they are broken Based on this, various ideas could be tested, for instance: 1. Before a successful gum call, consider `deviceId` to be an ideal constraint even if marked as `exact`. This would mitigate the issue of web applications using exact deviceId constraints. And this would beef up our privacy story as well. 2. Before a successful gum call, enumerateDevices could expose devices with `deviceId` equal to `default` instead of `""`. `default` given to `getUserMedia` would be treated as the empty string aka no `deviceId` constraint (like we might do for `setSinkId`). 3. After a successful gum call, device labels can be exposed. Fire a `devicechange` event so that web applications update their picker/states. 4. Before a successful gum call, enumerateDevices could expose devices with `label` equal to fixed values (say `default` or `default camera`...) instead of `""`. This might mitigate web applications not reacting to `devicechange` events. 6. Add permission granted status to the mitigation heuristics. These are only ideas though, the first thing is to understand the various breakages. -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/1019#issuecomment-2493370169 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 22 November 2024 09:58:04 UTC