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

Proposal: define default for all #189

Open
laukstein opened this issue Jul 17, 2018 · 23 comments

Comments

@laukstein
Copy link

commented Jul 17, 2018

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.

@CharlesStover

This comment has been minimized.

Copy link

commented Jul 20, 2018

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

This comment has been minimized.

Copy link

commented Jul 22, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Jul 24, 2018

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

This comment has been minimized.

Copy link

commented Aug 7, 2018

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

This comment has been minimized.

Copy link
Collaborator

commented Aug 8, 2018

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

This comment has been minimized.

Copy link

commented Aug 24, 2018

@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

This comment has been minimized.

Copy link
Collaborator

commented Aug 27, 2018

@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

This comment has been minimized.

Copy link

commented Aug 27, 2018

@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

This comment has been minimized.

Copy link
Collaborator

commented Aug 27, 2018

@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

This comment has been minimized.

Copy link

commented Aug 28, 2018

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

This comment has been minimized.

Copy link
Author

commented Aug 28, 2018

@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)?

grabilla g12168

@clelland

This comment has been minimized.

Copy link
Collaborator

commented Aug 29, 2018

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

This comment has been minimized.

Copy link

commented Oct 9, 2018

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

This comment has been minimized.

Copy link

commented Oct 19, 2018

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

This comment has been minimized.

Copy link

commented Nov 11, 2018

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 blacklist and that has to be modified whenever a vendor introduces a new value. Security filters should work as whitelists 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.

@ewanm89

This comment has been minimized.

Copy link

commented Jan 8, 2019

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

This comment has been minimized.

Copy link

commented Feb 7, 2019

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

This comment has been minimized.

Copy link

commented Feb 7, 2019

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

This comment has been minimized.

Copy link

commented Feb 17, 2019

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

This comment has been minimized.

Copy link
Collaborator

commented Feb 28, 2019

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.

@w3c w3c deleted a comment from MediaMaquina Feb 28, 2019

@sstelfox

This comment has been minimized.

Copy link

commented Feb 28, 2019

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.

@pabrai pabrai added this to New input in FP Engagement May 13, 2019

@pabrai pabrai moved this from New input to Questions in FP Engagement May 13, 2019

@Jamesernator

This comment has been minimized.

Copy link

commented Jun 4, 2019

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.

@clelland

This comment has been minimized.

Copy link
Collaborator

commented Jul 19, 2019

The work going on around issues #296, #298, #299, #300, etc, should help clear up a lot of the issues around this. If the proposed document policies and sandboxing are not covered by the Feature-Policy header, then a default allowlist makes a lot more sense; whether it is 'self', or 'none', or some concrete list of trusted origins.

eighthave added a commit to f-droid/fdroid-website that referenced this issue Sep 11, 2019
add HTTP Feature-Policy header to disable all unused browser APIs
https://developer.mozilla.org/en-US/docs/Web/HTTP/Feature_Policy

This site needs hardly any JS features, so disable them. There is no
way to set the default to none yet, once that is available, this
should switch to a simple "default 'none';"
w3c/webappsec-feature-policy#189

This scanner which I found via Mozilla Observatory recommends them:
https://securityheaders.com/?q=https%3A%2F%2Ff-droid.org%2F
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.