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

TL;DR: please read my answer in https://github.com/web-platform-tests/interop/issues/849#issuecomment-2489546740.

> 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. 

This isn't accurate. AFAIK only labels were gated on permission in the old spec.

> Chrome tried to deploy gUM-before-enumerateDevices and had to roll it back due to incompatibility with existing applications, hence this issue.

It might be time to try again.

> > > 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.

What existing applications? There must be some misunderstanding as I don't follow this at all. Firefox supports persistent permission through the `✅ Remember this decision` and I assure you we didn't need to do any of this, whatever this is.

> > 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.

Of course it does. It's the predominant video conferencing model that works in all browsers. Most users don't have multiple cameras facing them. So websites ask for the default camera (or remember the previously one) and add a ⚙️ settings page for making changes.

> > 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).

A website can prime for permission just once in Chrome, and assume devices on pageload work forevermore.

> 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.

Why has Firefox not seen any compatibility issues?

> > 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.

I'd like to see these existing applications.

The previous spec never specified permissions-before-eD, it specified permissions-before-eD-with-labels. You didn't need permission for eD. So any compatibility issue tied to permission seems specific to chromium.

-- 
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/1019#issuecomment-2489606903 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 21:48:09 UTC