-
Notifications
You must be signed in to change notification settings - Fork 154
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
Comments
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 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. |
Same suggestion for me: it could be useful to define a default to |
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. |
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. |
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. |
@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. |
@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 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 |
@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... |
@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 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 You could say something like " |
Maybe we could require to set up some kind of a report (see Reporting API) to be able to use |
@valtlai, probably best to Report things that fails because of restricted Feature-Policy header. Would basically be similar to CSP 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 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)? |
Feature Policy (and CSP, with the @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. |
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 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 |
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 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 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. |
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. |
Let me be very clear, this is stupid:
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. |
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 Then we made a So what we ended up with was immutable bundle aliases, eg 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 |
I think plain After that, you would enable features using other directives. That way, nothing would break by enlarging the scope of |
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: 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. |
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. |
Reading through some of the more recent responses it seems like there are two independent groups talking about different meanings of how 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 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 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. |
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. |
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). |
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. |
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. |
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:
That one-line view doesn't quite capture the current state of things. Here's a multiline list of current directives:
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: Pages that don't use any sensitive APIs should be able to just opt-out of this permissions just like what HTTP headers are already a significant chunk of total page weight, even with HPACK. This header is easily the biggest on simple pages. |
Off-topicI feel that the feature creep will kill this entire proposal (not the defaults idea). My counter-proposal would be: majority (all?) of these features require client-side JavaScript, why not set up these restrictions using JavaScript as well? |
@dimaqq 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. |
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.
I can't seem to come up with a good way to categorize the following directives:
These directives are deprecated and can be excluded:
I think that adding groups for If this sounds like a good idea I could create a separate issue. |
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. |
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:
|
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:
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 |
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 In 2024, introduce the Agents seeing a number in the permissions-policy header for a year they don't know of (e.g. Rinse and repeat. |
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... |
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. |
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? |
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 |
☝🏻 easily, don't use this proposal, let it die. |
@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 |
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. |
Yes, I misspoke. But I still maintain that the abandoning the proposal without an alternative doesn't seem better than this proposal. |
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.) |
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. |
@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. A default directive would simply leave the choice to the developer though. 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 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. |
I propose
Feature-Policy
adoptContent-Security-Policy
concept and be able to define all default, example:where similarity in CSP would be
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.
The text was updated successfully, but these errors were encountered: