Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Combined permission request is problematic #183

Open
marcoscaceres opened this issue May 19, 2024 · 6 comments
Open

Combined permission request is problematic #183

marcoscaceres opened this issue May 19, 2024 · 6 comments

Comments

@marcoscaceres
Copy link
Member

In requestPermission(absolute), the spec notes:

There is no algorithm for requesting multiple permissions at once. However, user agents are encouraged to bundle concurrent requests for different kinds of media into a single user-facing permission prompt.

Which is indicative that the permission model is not correct. This also sets a bad precedent for mixing multiple permissions policies.

We should fix this.

@marcoscaceres marcoscaceres changed the title Combine permission request is problematic Combined permission request is problematic May 20, 2024
@reillyeon
Copy link
Member

This text is adapted from a similar note in [MEDIACAPTURE-STREAMS].

@marcoscaceres
Copy link
Member Author

Right, but there the request permission to use is single permission descriptor? Or am I misreading? (not seeing the note... maybe it got changed since this spec got changed)

@reillyeon
Copy link
Member

I'm referring to the "User Agents are encouraged to bundle concurrent requests for different kinds of media into a single user-facing permission prompt" note under the step "For each media type kind in requestedMediaTypes, run the following sub steps, preferably at the same time". The effect of that step is that the site may request both "camera" and "microphone" permission at the same time if the device supports both audio and video.

@marcoscaceres
Copy link
Member Author

marcoscaceres commented May 22, 2024

Right, cool. I still think that the camera and microphone is a somewhat unique situation in the platform (those are some of the most privacy sensitive APIs on the Web).

I'm wonder if you agree that perhaps we could consider simplifying what is done here? At the same time, there is a little bit of pressure on "this ship has somewhat sailed" (like, we support this in WebKit somewhat... even if we require all there permissions).

Just seems that we are tying things that could be done more cleanly and extensibly, particularly as we continue to evolve this API.

@marcoscaceres
Copy link
Member Author

marcoscaceres commented May 22, 2024

Put differently, can we come up with what might be the ideal?... we don't need to commit to changing anything in the spec, but it's more conceptually... like, for me, it would be:

  • one permission policy: like "orientation-motion" (we can no doubt do better even)
  • and the then have .requestPermission({absolute: true})

Or something like that.

@reillyeon
Copy link
Member

I think this ship has sailed but I think an ideal design which limited itself to only the sensors required to implement the current capabilities this specification (i.e. just sensors for determining device orientation and motion) would require only a single permission. I don't think it is necessary to communicate the difference between absolute and non-absolute through browser UX. It's only useful internally because it allows developers to inform the browser that they don't care about compass heading and can therefore avoid activating an additional unnecessary sensor.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants