Re: [mediacapture-main] What is the purpose of requiring a successful gUM call before enumerateDevices? (#1019)

> FWIW, I do not think we can go back and weaken the privacy story. 

Gating eD labels to permissions does not weaken the privacy story IMO.
For example, Safari's model is already this one since permissions are ephemeral, so a UA can implement the same guarantees if it wishes to do so.

I would argue that forcing a gUM call can be detrimental to user privacy in some cases.

Consider the following case:
1. A frequent user of a VC application has given persistent permissions to avoid being prompted frequently.
2. This user starts the browser, and instructs the VC to join a meeting with the camera and mic off for privacy reasons. But wants the ability to turn them on in the middle of the meeting.
3. The user has several devices (e.g., two or more microphones or cameras)
4. In the middle of the meeting the user decides to participate in the meeting, but wants to select the right microphone and/or camera. This should occur without the UA prompting the user because the  user gave persistent permissions for all the media devices, so device selection occurs via an in-app device picker.

permissions-before-eD supports this use case without problems.

gUM-before-eD cannot support this use case correctly. The application has to choose between a broken UI or violating the user's privacy to produce a proper UI.

This use case is common for VC applications and it should be possible for UAs to support it if they want to support it.
 
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

Some examples:
* For Zoom I think it is the default for joining an existing meeting, and it is a prominent feature to start a new meeting with video off. For returning users with persistent permissions, device pickers are broken.
* Whereby before joining a meeting presents a dialog to choose camera and microphone. On Firefox an extra click is required for returning users with persistent permissions to make an initial gUM call so that the device pickers can be initialized. On Chrome the user goes directly to the UI with the correct device pickers. 
* On Dialpad meetings, you can configure it to start with camera/mic off. For returning users with persistent permissions it opens the camera/mic and closes it quickly in order to provide a good UI. In this case the application has to go against the user setting in order to respect the user's wishes. They choose the text carefully in the settings "Turn off camera while joining a meeting?" to inform the user that they actually open the camera. While working as intended in a strict sense, they should be able to do it without turning the camera off if that is the user's preference, but gUM-before-eD makes it impossible.  
* Zoho.com has behavior similar to Whereby. An extra click is required on Firefox for returning users for the gUM call, presumably to be able to get device information. I didn't see pickers, though. This application can also remember a setting to have the camera off by default, but, like Dialpad, opens and closes the camera and mic quickly.
* According to [this documentation](https://support.microsoft.com/en-us/office/turn-off-automatic-video-in-a-call-in-microsoft-teams-a32bd419-00a4-4da6-898c-242b745a21c7), scheduled meetings on Microsoft Teams start with video off. I have not tried this feature, so not sure if it breaks, but it might.
 
> 
> 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.
> 5. Add permission granted status to the mitigation heuristics.
> 
> These are only ideas though, the first thing is to understand the various breakages.

I think these ideas (and others) are worth exploring, hence why this issue has been filed.
It is clear that gUM-before-eD breaks existing applications and, for some use cases, forces applications to choose between proper UI and properly respecting user's privacy settings.


-- 
GitHub Notification of comment by guidou
Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/1019#issuecomment-2495428353 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Saturday, 23 November 2024 10:17:16 UTC