feature request: a 'default' directive similar to CSP's 'default-src'

[roycewilliams]

For simple sites that would like to adopt a 'default deny' or 'default self' stance for Feature Policy, a directive similar to the Content-Security-Policy default-src directive would be very useful (and could result in much shorter Feature-Policy headers for some use cases).

For example, instead of:

accelerometer 'none'; ambient-light-sensor 'none'; autoplay 'none'; camera 'none'; encrypted-media 'none'; fullscreen 'self'; geolocation 'none'; gyroscope 'none'; magnetometer 'none'; microphone 'none'; midi 'none'; payment 'none'; picture-in-picture 'none'; speaker 'self'; sync-xhr 'none'; usb 'none'; vr 'none'

... this could be the equivalent:

default: 'none'; fullscreen 'self'; speaker 'self'

Advantages:

• Reduced length: - Much shorter (and would maintain that shortness advantage as new directives are added in the future)
• Readability: Much easier to understand at a glance
• Forward-looking: Allows the default to be applied to any new directives in the future, without enumerating them

Obvious valid values could be 'none', 'self', and *.

[clelland]

I think this duplicates #189 and #208 -- and my general objection to it is still that it makes it very difficult for browsers to turn any existing browser behaviour into features, as any site which has adopted this may immediately break. (This is the same problem with sandbox, and I'd hate to replicate that here)

The equivalent policy a few years in the future might have to be extended to something like

default: 'none'; fullscreen 'self'; speaker 'self'; document-write *; images *; navigation *; forms *; scripts *; tables *; stylesheets *; user-fonts *; web-fonts *; pointer-events *; web-workers *; async-xhr *; timing *

just to re-enable web behaviours that have been carved out into policies. And that list may have to grow arbitrarily long in the future as well.

One possibility that I've raised previously would be to allow a setting which would disable by default all features with a defaut allowlist of 'self'; this would put a site into the same category as a cross-origin frame, with all of the features turned off that are disabled in such frames. Core features could be turned off as needed, and powerful features could be turned back on, again as needed. I think that would make your example work, without being a silent footgun.

[roycewilliams]

Apologies for the duplicate - though I would argue that duplicates are often a sign of a trend worth addressing (either in architecture, or in a FAQ). 😉

I definitely see your point about how default: 'none' could add significant friction for browsers adding more Feature Policy directives - especially when different browsers already have different levels of support! I'm glad that smarter people than me are properly pondering that challenge at scale. :) And I totally see how the current state is a tidy way to make each new directive require explicit opt-in.

As to the footgun problem generally ... with controls like Feature-Policy and Content-Security-Policy, we're already in a realm where a minimum level of understanding - and monitoring, such as with Report-To - is necessary. When controls can deny features, there's no way to escape that.

Some brainstorming snippets:

• Instead of 'none', picking a directive that makes site admins more explicitly aware of the potential problem of future breakage (such as - tongue in cheek - default: 'none-break-future-features').

• Sidestepping the major footgunning by simply by excluding 'none', but implementing with 'self' and *. This is pretty much what it sounds like you're gravitating toward.

The incremental proliferation of * that you've described would naturally reach a break-even point where the administrator could move from default: 'none' to default: *, and toggle their config accordingly. If site admins have the option, they can make that break-even decision for themselves.

If I have anything constructive to contribute further, I'll do so in one of the other thread. Closing - thanks for taking the time to answer.