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

Add a hook for implicitly granting or denying before requesting permission to use #413

Open
johannhof opened this issue Feb 3, 2023 · 2 comments

Comments

@johannhof
Copy link
Member

The permissions spec is already intentionally quite vague about how a user agent would choose to grant/deny a permission request, making it possible to forgo asking the user for permission where appropriate.

This can be used to e.g. automatically deny notification permission prompts when they were flagged as potential spam, or to add custom heuristics for automatically granting storage access to balance user annoyance and protection.

While some of these interventions are implementation-defined, it would also be nice to have a hook in this spec for use in other specifications that define steps to take before a prompt is surfaced to the user.

@johannhof johannhof changed the title Allow for implicitly denied / implicitly granted more explicitly Add a hook for implicitly granting or denying before requesting permission to use Feb 3, 2023
@annevk
Copy link
Member

annevk commented Feb 7, 2023

What kind of things did you have in mind? And would those run in parallel or on the main thread?

@jyasskin
Copy link
Member

jyasskin commented Feb 8, 2023

https://privacycg.github.io/storage-access/#dom-document-requeststorageaccess mentions

Note that when requesting permissions and deciding whether to show a prompt, user agents apply implementation-defined behavior to shape the end user experience. Particularly for storage-access, user agents are known to apply custom rules that will grant or deny a permission without showing a prompt.

But https://w3c.github.io/permissions/#dfn-request-permission-to-use doesn't actually give the UA an opportunity to apply that implementation-defined behavior: it says to ask for "express permission" no matter what.

I was thinking that it'd be easy for this to run in parallel, but actually, @johannhof's initial use reads some fields out of a relevant settings object, so we either need to queue back to a main thread or declare that some fields are constant and so safe to read from parallel contexts.

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

3 participants