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

> I think there's some misunderstanding here.

Certainly. The issue is that the requirement of gUM before enumerateDevices is incompatible with the way many Web applications have been written for a long time, which was to assume enumerateDevices results (among other things) are gated by permissions. 
Chrome tried to deploy gUM-before-enumerateDevices and had to roll it back due to incompatibility with existing applications, hence this issue.

> > Forcing the gUM requirement on implementations with persistent permissions makes persistent permissions largely useless, since one of the objectives of persistent permissions is to avoid constant prompts for frequent users of VC applications.
> 
> 100% agree the objective of persistent permissions is to avoid constant prompts.
> 
> But users who have persisted permissions won't incur any prompt when a fresh gUM call is made.
> 

The claim refers to the fact that the only practical way to implement the gUM-before-eD in a way that is fully compatible with existing applications is to do it with non-persistent permissions (or at least, making the browser always reply 'prompt' to permission queries before the first gUM, even if gUM won't actually prompt).

> So how does trimming enumerateDevices ahead of camera and microphone being turned on lead to _"constant prompts"_?
> 

Because the practical way to implement this in a way that doesn't break existing applications is to use non-persistent permissions, which would prompt often, like Safari does. 
An alternative would be to implement the UA such that it always replies 'prompt' before the first gUM, and not actually prompt if the permission was actually persisted. But even this hack would still break some existing applications that would unnecessarily show app-level explanatory dialogs asking the user to authorize camera and mic via a gUM call specific for this purpose. 
 
> > I agree that always prompting might have some privacy benefits, but this comes at the cost of making things more difficult or inconvenient for frequent users of VC applications.
> 
> 100% agree.
> 
> > I think this is an area where it is better to let UAs decide the tradeoff that works better for their users.
> 
> The spec allows UAs to implement persistent permissions, one-time permissions, even both.
> 

The concern is not what is possible or not, but compatibility with existing real-world applications.

> The purpose of not returning detailed device information without a recent gUM call is twofold:
> 
> 1. prevent tracking users across websites

The benefit of gUM over permissions here is quite limited, as trackers will need to call gUM anyway to get permissions. For cross-origin tracking, each top-level origin needs to call gUM successfully at least once to get permissions and successfully participate in cross-origin tracking. 

> 2. ensure interop between permission models
> 
gUM-before-eD does not give any interoperability assurances over permissions-before-eD. 

> A website that expects to list devices on pageload won't work in Firefox or Safari. This is [not hypothetical](https://bugzil.la/1923194#c1). Sadly it seems it's not uncommon to test against a single browser.
> 
It won't work on Chrome either (unless they have permissions, which requires gUM). The reason Safari has not seen any compatibility problems due to gUM-before-eD is that their permissions are non-persistent, so applications know they have to call gUM. 

> Both Safari and Firefox let users grant one-time permissions to camera and microphone by default. Even Chrome is [experimenting](https://developer.chrome.com/blog/one-time-permissions) with them as well:
>
The problem is not the various permission models browsers implement and modify over time.
The problem is that existing applications break with gUM-before-eD because they were written against the previous spec which stated permissions-before-eD.


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


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

Received on Wednesday, 20 November 2024 16:23:38 UTC