Repository navigation
Permissions policy #479
Description
This GitHub issue is for collecting web developer signals for Permissions policy.
The Permissions-Policy response header and the allow attribute for <iframe> elements sets whether a policy-controlled feature, such as an API, may be used in a document.
Browser support
- Chrome 108 (Nov 29, 2022)
- Chrome Android 108 (Nov 29, 2022)
- Edge 108 (Dec 5, 2022)
- Firefox: not supported
- Firefox for Android: not supported
- Safari: not supported
- Safari on iOS: not supported
Give us feedback
If you're pressed for time, but you want this feature to be available in all browsers, please give this issue a thumbs up 👍 reaction.
However, a much better guide for us is to know how you'd use this feature, and what you're having to do in the meantime. This helps us judge the priority versus other features.
Copy the template below in a comment, and add the details that matter to you.
## What I want to do with this feature
<!-- Add your specific use-cases, even if they seem obvious to you. -->
## What I'm having to do in the meantime
<!--
Are you having to use another feature instead, a polyfill, or is it blocking you completely?
Why are the alternatives worse than using this feature?
-->All comments are expected to adhere to the Code of Conduct.
Learn more
You can learn more about this feature here:
Activity
GwynethLlewelyn commentedon Mar 14, 2026
What I want to do with this feature
Essentially, replace the now-deprecated
Feature-policywith just one header, i.e.,Permissions-Policy.What I'm having to do in the meantime
Even though caniuse.com reports that 75% of all browsers support
Permissions-Policy, it's obvious that all these are Chromium-based browsers. Apple's Safari, which powers a billion Apple devices, does not recognisePermissions-Policy, and evenFeature-policyhas limited support.It's always annoying to have to send two headers that specify very similar configurations/settings because of a change in specifications. Since, as said,
Feature-policyis limited in many browsers, a better approach, IMHO, would be to lobby for direct implementation ofPermissions-Policyinstead, skipping whatever developer time was allocated by the browser developer to 'finish up' the now-deprecatedFeature-policyheader.('Annoying' in this context should be read as 'wasting unnecessary bytes on the payload')
One interesting possibility would be to have all policies 'off' by default and only modify those that are to be 'on'. Unfortunately, the number of policies that most developers expect to be present (such as support for Aria, or full-screen, or even snapshots...) is quite extensive as well, so any thoughts of saving bytes sent on the headers would probably be moot.
Alternatives would be to either have abbreviations for each setting (at the cost of making the headers less legible) or a very compact representation format, such as allowing an alternative directive configuration string using just two letters for each directive that is set to
'*', e.g., "_ARCMCP" would turn 'on' the policies foraria-notify,camera, andcompute-pressure. The first character,'_'is just a marker to say 'alternative configuration string follows', and the rest is just a sequence of two ASCII characters for each policy to be turned 'on' — which, in turn, would naturally require a specification of which policy each pair of characters encodes...