Proposal: define default for all

[laukstein]

I propose Feature-Policy adopt Content-Security-Policy concept and be able to define all default, example:

Feature-Policy: default 'none'
Feature-Policy: default 'none'; fullscreen 'self'

where similarity in CSP would be

Content-Security-Policy: default-src 'none'
Content-Security-Policy: default-src 'none'; img-src 'self'

Otherwise we would be stuck to define all features separately, and since the features list will grow more and more, without the global default it likely will harmful web.

[quisido]

I second this, and came here for the same suggestion. I would prefer my features be blacklisted by default and whitelisted as needed. My Feature-Policy header is ridiculously long when I have to explicitly define all of them as 'none'.

I also fear that as time progresses, browsers and devices will add non-standardized features to their feature lists. It will become nearly impossible to blacklist all non-standardized features.

[nico3333fr]

Same suggestion for me: it could be useful to define a default to 'none' and then define what we need on the website/app.

[eeeps]

Just a note to say that this relates to some of the discussion here: #129, where a default for a specific subset of policy controlled features (client hints) was proposed.

[olmari]

Definately thumbs up for at least possibility of defining default policy, having a (growing) blacklist with no default is insanity.. Even if some feature gets added and then a site with default policy breaks, it is matter of allowing that one policy.. In current form it is impossible to manage every possible new addition by hand.

[ojanvafai]

We already have some experience with this with iframe sandbox where we are having difficulty adding new directives because they break pages. With FeaturePolicy, it would be a bit different because we can add new directives without having them be part of the default policy, but it's still hard for me to see how we would be able to add new directives over time to the default policy. With iframe sandbox we can at least prioritize it due to the security benefits.

It's difficult for browsers to ship things that break web sites, especially since many sites are unmaintained, so the ease of sites fixing when we break them doesn't really mitigate that concern.

[olmari]

@ojanvafai (and all whom may be concerned) AFAIK What we (at least me) are wanting to have an way to tell desired default policy/policies. So without any default defined standard could very well be "opt-in", but if header has something like default 'none' then honour that and deny everything if not told otherwise..

This way sites not having this header at all will continue to work as is today, and administrators who want's to just blacklist certain things regardless of new possible directives can do so, but it would also allow most concerned admins to introduce an default policy and then whitelist allowed ones.

[clelland]

@olmari, the problem I see with that proposal is that it makes it far more difficult for Feature Policy to be used to remove features from the platform -- we've done this with synchronous XHR, and are looking at other APIs, like document.write, as features we'd like developers to be able to disable. A default 'none' policy would break sites that use those features, certainly, but also any other features that are put under policy control in the future, regardless of how prevalent they are.

I'd love for browsers to be able to experiment with making bigger, more fundamental parts of the platform into policy-controlled features. I'd love for JavaScript, or navigation, to be features that could be disabled in certain contexts, for instance -- if you weren't aware of that, and had set a default 'none' header at some point in the past, then your site could be completely broken, with no warning at all.

[olmari]

@clelland then you don't just use "default none" policy... I don't know much more clearer I can be on my proposion... Having written no policy would be same as current behaviour. having written default none policy would do just that... All admin configurable...

[clelland]

@olmari, I realize that you mean for there to be no behaviour changes without explicitly setting the default. The problem that I see is that setting such a default on your site is necessarily a huge risk -- your site would be at far more risk of breaking with future browser revisions than has ever been the case in the past.

Although that's probably not the reality of the situation -- in reality, the existence of such an option, especially if it had any significant level of adoption on the web, would mean that browser vendors would be effectively barred from introducing any new features which would break content on all of those sites. Every new feature decision would have to include serious consideration and discussion about the impact to all of the sites which use default 'none', because breaking compatibility with significant portions of the web isn't something to take lightly -- even if they've opted in.

I do think that I understand the original concern, and the problem with having to specify an ever-growing policy of features to disable. If there were a way to distinguish between "powerful features which you want to think twice about using or granting to frames" from "fundamental features of the web platform", and apply a uniform default to those, then there might be a way to make the proposal work. Without that, it either seems very reckless on the part of the developer, or else severely impacts what kind of features can be defined (which I suspect is the more likely outcome).

Alternative strawman proposal: what if there were a way to set the default for all features which have a default allowlist of 'self'? Those features are already disabled by default in cross-origin frames, which means that people have already at least considered the impact of having them disabled widely. The difference would be that you get to disable them all for your top-level document as well, with a single directive.

You could say something like "default 'self'='none'" (bikeshed colour TBD) or the much more permissive "default 'self'=*" without affecting the operation of features like navigation, scripting, images, forms, or such fundamental 'features'.

[valtlai]

Maybe we could require to set up some kind of a report (see Reporting API) to be able to use default? The browser would report when it’s going to support the feature policy for a feature in use on the site.

[laukstein]

@valtlai, probably best to Report things that fails because of restricted Feature-Policy header. Would basically be similar to CSP report-uri. I really hope we wouldn't need additional header for it.
Perhaps report-uri must be supported also in Feature-Policy header.

Since Feature-Policy are growing bigger affecting not only sensors access, but also UI like animations, fullscreen, JavaScript, etc., things gets more complicated and I hope will not break Web before spec is fixed or depreciated. For example Feature-Policy: default 'none' might break "all" while Feature-Policy: default 'safe' might be fine.

Has anybody thought how Feature-Policy would be affected by browser settings, if Feature-Policy would overwrite browser settings or opposite (I mean these might all be browser defaults or some manually customized by user)?

[clelland]

Feature Policy (and CSP, with the report-to directive) are both being integrated with the Reporting API -- see §9. Reporting, which makes use of an independent Report-To header, rather than report-uri.

@laukstein, I think your other question has to to with permissions -- that screenshot appears to be about setting the default permissions for various APIs. Feature Policy and Permissions do interact, as they affect many of the same features.

In general, the Permissions API is about asking the user whether a particular action is okay, while Feature Policy allows the developer to disable features, or to grant them to cross-origin frames. It's a complicated interaction, but essentially both of the APIs have to agree to allow a feature to be used in order to enable it. If either party (user or developer) says no, then the site cannot use the feature.

[AfroThundr3007730]

Although that's probably not the reality of the situation -- in reality, the existence of such an option, especially if it had any significant level of adoption on the web, would mean that browser vendors would be effectively barred from introducing any new features which would break content on all of those sites. Every new feature decision would have to include serious consideration and discussion about the impact to all of the sites which use default 'none', because breaking compatibility with significant portions of the web isn't something to take lightly -- even if they've opted in.

I can see this being very useful for endpoints like a REST API (like in #208), which would use precisely zero of those features, and even completely static sites (e.g. readthedocs for said API) would find this useful. Just like with CSP, setting default-src none would break a more dynamic site immediately, but then you start allowing the origins you need (like 'self'), enabling specific features (allowing unsafe-inline), etc. If a new feature gets added later, you go back and enable it if you need it. The same would apply here.

If part of your site suddenly became very broken overnight after a browser update, you know where to start looking (at least, that's my thought flow after having set such a restrictive security policy). For the small number of people who would find it useful to disable everything, they would likely be more aware of what probably caused breakage, should it occur. Even better if the browser console tells them what's breaking the site, like they do with CSP. Reporting would also help with that, whenever that gets added.

I don't see the default 'none' getting used by very many sites, but it should be an option for those who want to use it. The majority of sites would probably stick to the default policy or set default 'self' (if they implement it at all), and would be unaffected.

[sstelfox]

I don't see the default 'none' getting used by very many sites, but it should be an option for those who want to use it. The majority of sites would probably stick to the default policy or set default 'self' (if they implement it at all), and would be unaffected.

I tend to disagree with this, especially on sites as they're developed. Setting the default wouldn't prevent you (the developer) from using any of the APIs, it just means you have to be cognizant that when you add features you are sure to whitelist them. Personally I see this as a huge benefit as a developer to prevent third party scripts and resources from doing things I don't want.

From what I've read so far about this proposal the default doesn't have to be none but could be any of the valid origin specifications. The two most useful IMHO are self and none. The self default would likely cover some of the earlier concerns about feature expansion in browsers as well, even though new features likely couldn't / wouldn't be usable until a developer made changes to the site anyway.

A casual example of this (and a straw man so take it in the spirit it's given), is that of embedding a youtube video. If I have a default policy of either self or none, when embedding I could prevent the youtube iframe from attempting to enable notifications for the user (I know youtube doesn't do this, but they could in the future, as could any other site that embeds content like this).

Those requests to use functionality are outright frustrating for users when they're not expecting them and I'd much prefer to control that interaction.

[yahesh]

Please implement a default directive. I'm thinking of implementing Feature-Policies on all of my sites but am not willing to name each feature individually. So this is a setting-a-default-is-possible-and-I-adopt-this-header or setting-a-default-is-NOT-possible-and-I-DON'T-adopt-this-header decision for me.

Maybe something to consider: This header is meant to be a security filter where additional values are supposedly introduced as needed by individual browser vendors. At the same time you allow default values to be "*" (allow all). This means you are implementing a security filter that works as a blocklist and that has to be modified whenever a vendor introduces a new value. Security filters should work as allowlists so that the person defining it knows exactly what is (going to be) allowed. Or to put it more frankly: Having allow-all defaults is a bad decision. To remedy this bad decision people ask for a functionality to fix this broken design, namely allowing us to set a senseful default value.

Edit: More inclusive wording.

[ewanm89]

Let me be very clear, this is stupid:

add_header Feature-Policy "autoplay 'none'; camera 'none'; document-domain 'none'; encrypted-media 'none'; fullscreen 'none'; geolocation 'none'; microphone 'none'; midi 'none'; payment 'none'; vr 'none'" always;

The site has no <script> tags, it is a single html file, without any media of any kind. A restful API is in much the same situation. This kind of blacklisting policy is totally stupid in any security context. Always blacklist all and whitelist just what one wants. Your specification does not allow that.

Oh, and I don't want to have to sit down and set such a policy again, or edit it cause a new feature is added that I'm not using anyway.

[triblondon]

I wonder if a good compromise here is to define some 'bundle' policies.

On the polyfill service we had the problem of people needing to create a very long string of required polyfills. The first thing we did (very unwisely) was to add an all alias, which includes all current and future polyfills. This turns out to be a really bad idea (for example when we shipped Intl, people requesting all were getting every single locale pack, some 25MB of JS!).

Then we made a default alias, which was a movable beast that gradually encompassed more and more polyfills, but we started to find we were breaking sites by adding more polyfills into the group, even though we restricted it to the most common features only.

So what we ended up with was immutable bundle aliases, eg default-3.6, default-3.7, so every time the makeup of the 'default' bundle changed, the alias would also change.

While this comparison isn't completely perfect, I think the solution we ended up with works well for feature policy: we could have some bundle names like antipatterns-1, user-consent-1, and if a new policy is added that guards an antipattern, then a new antipatterns policy is also created.

[ExE-Boss]

I think plain default 'none' should disallow everything that isn’t pure JavaScript (i.e. no DOM, no window global (globalThis would be used instead), no nothing).

After that, you would enable features using other directives.

That way, nothing would break by enlarging the scope of default as the scope would be maximum from day 1.

[Jamesernator]

I would propose an alternative of requiring a date to be provided and that whenever a feature is implemented it has an associated date.

For example we might have the following policies with their dates of addition:

foo-bar : 2018/07/27
baz-bar : 2018/01/23
boz-bar : 2020/11/14
// etc

Now if an header like so is given by a site: FeaturePolicy: default 2019/01/01 'none' is given then foo-bar/baz-bar would be included but boz-bar would not.

---

How dates would be associated with a policy wouldn't really matter, all that would really need to be a requirement is that a browser couldn't add a new policy for a date in the past.

[ojanvafai]

Please keep discussion focused on productive debate of the issues. I've deleted the most recent comment on this issue as it consisted solely of a personal attack, which violates the W3C code of conduct (https://www.w3.org/Consortium/cepc/). Repeated violations will result in being blocked from commenting on the repository.

[sstelfox]

Reading through some of the more recent responses it seems like there are two independent groups talking about different meanings of how default should behave.

Originally it was about setting the policy for any features not explicitly otherwise listed in the rest of the feature policy. Specifically, "If my feature policy doesn't mention feature X what policy should be applied". This covers new features that haven't been defined when the policy was configured and prevents having to specify none or self on each of the many different features that most sites won't use.

The second camp that has recently started up, seems to be more discussion what the default setting for each feature should be and have it defined by the w3c policy rather than a developer set default. This is along the lines of "use the default feature settings as defined by the w3c as of 2019-02-28". As other have mentioned, this would be a thorny and contentious road. There is likely no good default set that won't hurt sites out there.

There likely shouldn't be defaults when the header isn't present as has been done with every other security control based on HTTP headers, and when the header is present it only makes sense to allow the developer to set the default policy for everything, then override specifics.

Back to the original feature, the only argument against being able to set a default policy (please correct me if I've missed something) seems to be that a future feature addition might break existing sites that haven't changed. I don't think this will ever be an issue as long as an existing feature is never broken up into more granular features.

For example if Clipboard got broken up into Clipboard-Write and Clipboard-Read, and Clipboard was deprecated the default setting might break existing web apps that rely on doing one of those functions. Preventing this kind of split can be done at the w3c policy level and as long as the developers of the policy are cognizant of this risk there shouldn't be any issue.

In any other case, the only time a default setting would break any functionality is when new functionality is being added to the web app that requires a change to the feature policy. In this scenario the web app is actively being changed and the developer will already have to deploy a new version of the code (it's also worth noting that this would be adding new features to the site, not just a minor bug fix release).

In this case part of the release of the new version would require the header being updated as well to allow for the new feature. This is the same level of effort as other security mitigations such as CSP headers and I think is completely reasonable.

[Jamesernator]

This is along the lines of "use the default feature settings as defined by the w3c as of 2019-02-28". As other have mentioned, this would be a thorny and contentious road. There is likely no good default set that won't hurt sites out there.

Actually my proposed idea doesn't depend on the W3C managing the dates just that a browser never adds a new policy for a date in the past, each browser could manage their own list simply based on commit date or similar.

The date would be a "I have checked my site works at this date" hence if a new policy is added it should not affect any page which gives a date before the date of the new policy, this doesn't require browsers to agree or even have any rules around it other than "a date for a new policy must not be in the past". This is why I think the date strategy is feasible and very non-thorny and shouldn't even be contentious.

[runthis]

I know this discussion is leaning towards 3 years old now. Does it seem possible in 2021 to disable all by default? On my portfolio website I don't foresee needing any permissions and would happily enable them one by one if I did (much like how CSP works).

[sandorvasas]

I've just come across this header and the intuitive way to me would be to disable all by default and explicitly enable stuff in the header. I'm surprised this is an unresolved issue.

[olmari]

Mine 2 cents is still basically as @sandorvasas said, in additition with possibility in header to define default that caters to everything. Thus if nothing is done, nothing happends, if site admin has defined default then that is used if no direct match exist.

[Seirdy]

Adapting something I posted on Fedi a few days ago:

Every new web feature wants its own entry in this massive chonker of a header, and there’s no one place to view all the directives. Here’s where we’re at now:

Permissions-Policy: accelerometer=(),ambient-light-sensor=(),attribution-reporting=(),autoplay=(),battery=(),camera=(),clipboard-read=(),clipboard-write=(),conversion-measurement=(),cross-origin-isolated=(),direct-sockets=(),display-capture=(),document-domain=(),encrypted-media=(),execution-while-not-rendered=(),execution-while-out-of-viewport=(),focus-without-user-activation=(),fullscreen=(),gamepad=(),geolocation=(),gyroscope=(),hid=(),idle-detection=(),interest-cohort=(),magnetometer=(),microphone=(),midi=(),navigation-override=(),otp-credentials=(),payment=(),picture-in-picture=(),publickey-credentials-get=(),screen-wake-lock=(),serial=(),shared-autofill=(),speaker-selection=(),storage-access-api=(),sync-script=(),sync-xhr=(),trust-token-redemption=(),usb=(),vertical-scroll=(),wake-lock=(),web-share=(),window-placement=(),xr-spatial-tracking=()

That one-line view doesn't quite capture the current state of things. Here's a multiline list of current directives:

     1	accelerometer
     2	ambient-light-sensor
     3	attribution-reporting
     4	autoplay
     5	battery
     6	camera
     7	clipboard-read
     8	clipboard-write
     9	conversion-measurement
    10	cross-origin-isolated
    11	direct-sockets
    12	display-capture
    13	document-domain
    14	encrypted-media
    15	execution-while-not-rendered
    16	execution-while-out-of-viewport
    17	focus-without-user-activation
    18	fullscreen
    19	gamepad
    20	geolocation
    21	gyroscope
    22	hid
    23	idle-detection
    24	interest-cohort
    25	magnetometer
    26	microphone
    27	midi
    28	navigation-override
    29	otp-credentials
    30	payment
    31	picture-in-picture
    32	publickey-credentials-get
    33	screen-wake-lock
    34	serial
    35	shared-autofill
    36	speaker-selection
    37	storage-access-api
    38	sync-script
    39	sync-xhr
    40	trust-token-redemption
    41	usb
    42	vertical-scroll
    43	wake-lock
    44	web-share
    45	window-placement
    46	xr-spatial-tracking

The above example excludes client-hints permissions which allow delegating permission to read client hints to other domains.

You can view all the perms supported by the Chrome DevTools Protocol at once. A subset is documented in a non-normative companion document to the main Permissions-Policy spec.

I found some scattered documentation for a few perms that have been implemented by Chromium:

• otp-credentials
• direct-sockets
• storage-access-api

Pages that don't use any sensitive APIs should be able to just opt-out of this permissions just like what sandbox allows. A default directive would allow these pages to switch to selective-allowing while still letting others ignore it and perform blocking on a case-by-case basis.

HTTP headers are already a significant chunk of total page weight, even with HPACK. This header is easily the biggest on simple pages.

[dimaqq]

Off-topic

I feel that the feature creep will kill this entire proposal (not the defaults idea).
Everyone and their uncle can add yet another directive (floc, otp) which becomes otp-out for existing web sites as it is now.
(opt-in if the defaults idea becomes the norm)

My counter-proposal would be: majority (all?) of these features require client-side JavaScript, why not set up these restrictions using JavaScript as well?
Case in point would be requestStorageAccess for storage-access-api.

[DanWin]

@dimaqq
The main point of having a Permission Policy in place, is to restrict what you can do with JavaScript. Allowing to change the Permissions with JS would also allow 3rd party scripts to ask for permissions, which you may not agree with. Or in case of an XSS-like security breach, an attacker could inject some code that will ask for various permissions. So it absolutely makes sense to have a server-side generated header, which tells the browser exactly what it is allowed to make use of.
The only way that JS could have the same protection is, if you setup the policy as the very first thing, before any other JS is getting executed and from then on the policy can't be changed. This will be difficult to enforce though, especially when making use of frameworks that perhaps inject JS before you have a chance to hook in your own JS.

The current opt-out policy, makes it hard to stay up-to-date. New features will get added all the time, so a site operator wishing to opt out from all of these would have to update the header every once in a while.
But if we consider a default option to disable all features by default and only selectively enabling them, when needed, a site operator could define a strict rule of exactly the permissions the site needs. When new features become available, they are not suddenly going to be used by the site operator just because they exist. A developer would have to change the code and it would be an easy thing to then also update the header when necessary.

[Seirdy]

I admit that bundling every permission into one universal directive does expose a problem: a site that works with such a directive today might break tomorrow as a new permission is introduced for features the site uses.

I therefore propose simplifying the policy by following a different approach: group many related directives together.

• All policies that involve accessing devices can be grouped under a devices directive. This can include:
  • accelerometer
  • ambient-light-sensor
  • battery
  • camera
  • gamepad
  • gyroscope
  • hid
  • magnetometer
  • microphone
  • midi
  • serial
  • speaker-selection
  • usb
  • xr-spatial-tracking
• All policies that involve window-management, i.e. performing tasks that are normally handled by a window manager/compositor, can be grouped under a window-management directive. This can include:
  • fullscreen
  • picture-in-picture
  • window-placement
• Policies that change how the browser prioritizes a webpage (e.g. regarding throttling, focus) can be grouped under a priority directive. This can include:
  • autoplay
  • cross-origin-isolated
  • execution-while-not-rendered
  • execution-while-out-of-viewport
  • focus-without-user-activation
  • sync-script
• All policies that involve sending data between the UA and the OS can be grouped under a talks directive. This can include:
  • clipboard-read
  • clipboard-write
  • display-capture
  • otp-credentials
  • publickey-credentials-get
  • storage-access-api
  • web-share
• Remaining policies that involve tracking that don't fall in the above categories (i.e., features explicitly made for forms of tracking, but not necessarily privacy-invasive if you ignore fingerprinting) can fall under a tracking directive. This can include:
  • conversion-measurement
  • interest-cohort
  • trust-token-redemption
• All client-hints directives can fall under a ch directive.

I can't seem to come up with a good way to categorize the following directives:

• direct-sockets
• encrypted-media
• idle-detection
• navigation-override
• payment
• screen-wake-lock
• shared-autofill
• sync-xhr
• geolocation
• vertical-scroll
• wake-lock

These directives are deprecated and can be excluded:

• document-domain

I think that adding groups for devices, ch, and window-management shouldn't be as controversial as the rest. Just like default-src in the CSP, webpages could first specify their "defaults" this way and then specify individual overrides. This could significantly reduce the size and complexity of the header.

If this sounds like a good idea I could create a separate issue.

[theherk]

It still seems like, even if you use several groups, it should be the option of the site's administrator to choose explicitly to allow or disallow all features, even if that means a breakage when permissions are added. As long as it isn't the default, this makes sense.

[PeteX]

These policies seem very difficult to use without having a way of disabling all features by default. Very few iframes are going to want access to features like USB, but ideally these features should be disabled when they are not required. (If they're enabled and the embedded site gets compromised, it can spam users with permission requests, and some people will say yes.)

I take the point about future-proofing, where for example in the future, there might be a directive that restricts the right to use images. I see two ways round this:

• You could split the directives between additions to the web platform and sandboxing. If in the future, web pages might be granted access to the brain-computer interface, that would default to disabled, because it's new and so legacy sites won't depend on it. Conversely, a directive that restricts use of images would default to enabled, because legacy sites probably will depend on images.

• The directive which disables everything could come with a version number or a date. (I know this has been discussed a bit already.) It disables everything which was in the standard as of a certain time.

[jsleeio]

I arrived at this issue when, like some other folks, I just wanted to disable it all, and disable all future new features also, with the knowledge that I'll need to enable them if I want them. The situation that has me concerned is the intersection of three possibilities, none of which are unusual or unlikely:

1. new capabilities being added to browsers that I definitely don't want to be used on my site
2. third-party-hosted Javascript things that I am intentionally using, such as in-browser performance monitoring tools, comment platforms, etc
3. changes — whether legitimate or via a security breach — to the Javascript in (2) to make use of those new capabilities

Whitelisting means there should be no window of time in which those new capabilities are used on my site. I don't know how else to prevent that. (edit: except to use fingerprints for everything, which is a perfectly reasonable step, but in my experience quite rare in vendor documentation, which makes it a hard sell to developers)

The current approach appears to require responsible site operators to keep up to date with all new browser tech rather than focusing on the tech they're actually using. I don't think that's very respectful of their time

[Seirdy]

I thought of a solution that should address concerns surrounding both header bloat and future proofing:

Bundle all current permissions-policy directives into a single new directive called 2022. A site with Permissions-Policy: 2022=() would disable all the aforementioned permissions.

In 2024, introduce the 2024 permission which includes all of 2022 as well as any permissions introduced since then.

Agents seeing a number in the permissions-policy header for a year they don't know of (e.g. 2384) can just pick a lower year that they support.

Rinse and repeat.

[olmari]

Why is this is hard? Nothing else will work well, but treat without any policy as usual, and have policy to have option for "default" which caters for any current and future things (be it block all or whatever "default" is considered at any point in time, doesn't really matter in context), and then the fine-grained control for those who want to do it properly... and even then leave possibility to have rest of stuff as default so future is catered... I can't believe this is gone on for years on end while only sane solution is simple...

[vphantom]

This header was quite simply designed wrong and needs a backwards-compatible syntax added to have its use reversed. CSP was done right and I have yet to understand why this one wasn't. Being able to disable all and to enable specific permissions is the only sustainable way to go.

[kifd]

Yet another +1 to wanting a default policy setting, just like CSP. How is it considered best practice to individually blacklist an ever growing feature set, rather than whitelist the features you actually want?

[vphantom]

Is there any other way to get the W3C's attention about this?

It's been over 5 years and we've been through one header change already (FP → PP) so clearly they either don't care or never even noticed this major design flaw which is costing everyone (interested in compliance) time to maintain the list of features, and bandwidth to send those headers to browsers.

A simple all=() ahead of the more specific permissions we do use (if any) would be fine and backwards-compatible.

[dimaqq]

Is there any other way to get the W3C's attention about this?

☝🏻 easily, don't use this proposal, let it die.
If the origin servers don't send this header field, the browsers will not enforce it.
Someone will eventually come up with a better proposal, or a better concept.

[theherk]

@dimaqq I think I get your point, but I don't think just throwing our hands up will do much either, as we still have to make these things work and abandoning CSP Permissions-Policy simply isn't going to happen. If browsers stopped supporting it, we'd be going the wrong direction. Better the proposal is ideally adopted at some point. If a better proposal exists or comes up, then that proposal can be adopted. In the meantime, this seems to be fairly well-liked.

[Gunni]

I don't think anyone here is talking about the content security policy since it has a sane default policy. The permission policy on the other hand does not which is what we are talking about here.

[theherk]

Yes, I misspoke. But I still maintain that the abandoning the proposal without an alternative doesn't seem better than this proposal.

[vphantom]

In our case we're forced to output that header in order to pass basic security scans so I can't let it die. :( At best I could reduce the header to almost nothing, but that would defeat the purpose of promising to behave. As it stands, our header has 62 of the 66 known features explicitly disabled and I have to search for new features regularly. I could probably remove some benign stuff to bring it down to 20-30 but I'd still have to regularly hunt for new offenders.

There have been several well-designed, backwards-compatible suggestions here these past 6 years and yet not a peep from the W3C to at least acknowledge the issue. They even mention in https://www.w3.org/TR/permissions-policy/ that "The web platform provides an ever-expanding set of features" and yet still maintain that selectively disabling individual features we know about is appropriate.

It is somehow the webmaster's responsibility to discover new features as they arise and to add them to an ever-growing deny list in order to correctly promise good behavior and to help deny access to misbehaving third parties (included JS, PunchOut frame parents, etc.)

[yannikbloscheck]

The header obviously gets way too big, if you actually want to disable most things. It's just frustrating. This really needs to be finally solved.
It's obvious a default directive is needed. No matter if it actually will be called default=(), all=() or anything else.
I really can't understand why this is being ignored for so long. Apparently this has been discussed and requested for over five years now...

[Seirdy]

The header obviously gets way too big, if you actually want to disable most things. It's just frustrating. This really needs to be finally solved. It's obvious a default directive is needed. No matter if it actually will be called default=(), all=() or anything else. I really can't understand why this is being ignored for so long.

@yannikbloscheck If you read the discussions you cited, you would know that a plain default-deny directive would not be forwards-compatible and is therefore not an option. Defining new meta-directives with specific static inheritance rules is a better option.

[yannikbloscheck]

@yannikbloscheck If you read the discussions you cited, you would know that a plain default-deny directive would not be forwards-compatible and is therefore not an option. Defining new meta-directives with specific static inheritance rules is a better option.

@Seirdy I read your ideas.
The directive groupings for feature areas is a good idea, but practically those group directives would need to be extendable, which would lead to the same problems. I still hope such groups will be implemented though, because it's a great idea anyway.
The directive groupings by point in time (or probably rather version number) would solve many of these problems. Web developers still would need to update the policy regularly to deny as much as possible. Also browser developers would need to agree every time what is included in each version. Also not a bad idea either.

A default directive would simply leave the choice to the developer though.
Maybe I don't care about being forwards compatible with any new (or even existing) access. Then I choose default=(). Maybe I want to allow anything new for my site by default. Then I could choose default=(self) etc.
If I want to be a responsible developer, I have to keep myself updated with what is added to this header in all cases anyway.
There are many other security headers that a web developer can use to shoot their future self in the foot by using too restrictive choices. But all those headers still exist anyway.

I can still understand the fears the browser developers have about this in regards to forward-compatibility. Especially as they don't really have to worry about all the extra unnecessary traffic the current solution causes. The browser developers probably would be forced to heavily communicate some new directives and have longer roll-out times. Still any developer worried about having anything break ever could just leave the default directive out or set a very permissive one. The documentation by the browser developers etc. could for example suggest default=(self) as the best choice.

The main thing though is that this has been a problem for over five years. While there has been much discussion about whatever problems might happen with any solution in the future, there has been a real problem (incredible header bloat) in practice for all this time and it isn't getting solved.