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: https://github.com/WICG/feature-policy/issues/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 Githubissues.

Githubissues is a development platform for aggregating issues.