Skip to content

Allow for User Agent discretion when checking permission policy - #572

Open
jkarlin wants to merge 5 commits into
w3c:mainfrom
jkarlin:selective_permissions
Open

jkarlin wants to merge 5 commits into
w3c:mainfrom
jkarlin:selective_permissions

Conversation

@jkarlin

@jkarlin jkarlin commented Jul 30, 2025 •

Copy link
Copy Markdown

The Selective Permissions Intervention allows the UA to Disable features for a given permissions policy check.

While small, this is a significant change in the sense that two calls in the same browsing context can have different responses. Notably, even if allowedFeatures says a feature is allowed, it may not be allowed for particular invocations. Any suggestions for additional prose/warnings are welcome.


Preview | Diff

Comment thread index.bs Resolved
Comment thread index.bs Resolved

@domfarolino domfarolino left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @clelland, what do you think about this?

@clelland

clelland commented Feb 4, 2026 •

Copy link
Copy Markdown
Collaborator

In general, I'm a fan of the idea that the user agent should be the ultimate arbiter of whether a feature is allowed or not, and even if the permissions policy structure is set up perfectly by all parties, the UA may have additional knowledge that a feature should not be allowed in a given context.

I like that this phrasing only allows the agent to deny access, and not to arbitrarily grant access as well.

One point about the location of the check; since Define an inherited policy doesn't call through to Is feature enabled, this will mean that it's possible for the user agent to intervene like this and disable a feature in one document, but for the same feature to be enabled in one of its embeds. I don't think we've enabled that situation before. I'm not against it, since again, the browser makes that choice, but it might make it easier for sites which are being blocked to find loopholes.

We should also consider whether the (rather neglected) JS API allowsFeature() and friends should return false in this situation (it's unclear, since that text says "allowed by policy", and doesn't link anywhere useful โ˜น๏ธ)

@annevk for thoughts as well

@scheib

scheib commented Feb 27, 2026

Copy link
Copy Markdown

I'm supportive of the patch, but suggest inlining a note sharing the example of protecting against advertisement scripts. This would help the spec be readable with example and not require reader indirection.

@jkarlin

jkarlin commented Mar 3, 2026

Copy link
Copy Markdown
Author

@scheib good idea, I've described the example inline.

@jkarlin

jkarlin commented Mar 3, 2026

Copy link
Copy Markdown
Author

@clelland I added a bit to the allowsFeature API, please take a look.

@ghost

ghost commented Mar 25, 2026

Copy link
Copy Markdown

Please allow my third party app access. I'm not receiving messages

@arichiv arichiv closed this Oct 26, 2026
@arichiv arichiv reopened this Oct 26, 2026
@arichiv

arichiv commented Oct 26, 2026

Copy link
Copy Markdown
Member

This LGTM but @clelland was already reviewing so deferring to him

This branch has not been deployed

No deployments
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

Successfully merging this pull request may close these issues.

5 participants