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

"All" directive should be a possible feature name #327

Closed
emilfihlman opened this issue Jul 19, 2019 · 3 comments
Closed

"All" directive should be a possible feature name #327

emilfihlman opened this issue Jul 19, 2019 · 3 comments

Comments

@emilfihlman
Copy link

Imho it should be possible to do

Feature-Policy: all 'self'; geolocation 'self *.domain.tld'

or even better, just

Feature-Policy: all 'self'; geolocation '*.domain.tld'

to allow all features for self and allow only some features for other origins as a clear and secure way to limit access. Instead currently, without such a wildcard/catchall "all" directive, you must use an ever changing long list to define all possible cases and features. This increases configuration size needlessly and increases threshold to use.

Iirc CSP has something similar already with default-src.

@clelland
Copy link
Collaborator

I think this is essentially the same request as in #189 -- If not, please re-open.

I think that a default like that might be possible -- but only once we resolve #296, and split off the document policies and sandboxing from this spec. At that point, it should be reasonable to set a default allowlist, whether 'self', 'none', or some list of trusted origins.

@emilfihlman
Copy link
Author

@clelland imho there is absolutely no need to wait for #296. Having an all/default-feature/so-on directive has no bearing on how features are divided across different types of policies. It also does not affect anything that comes after it.

You should definitely resolve #189 in favour of adding the default directive as currently not having one stands in the way of adoption.

@igrigorik
Copy link
Member

To the contrary, we should be very careful with providing an 'all' policy. The moment we introduce that and any site deploys it, we create a web compatibility risk whenever we add any new Feature Policy, because there is no way for us to know if the new policy might break existing sites that opted in into 'all' at earlier time. In a similar way, different browsers might implement different policies at different times, so it's impossible to reason what "all" actually means.

Requiring an explicit opt-in, instead of opt-out policy used by sandbox, was one of the core motivations for why we need FP: https://discourse.wicg.io/t/proposal-sandbox-policy/1414 — see section on opt-in vs opt-out.

This is the same issue that @ojanvafai raised in #189 (comment).

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