A new security header: Feature Policy | Hacker News Reader

A new security header: Feature Policy

scotthelme.co.uk

88 pointsdetaro63 comments

I'm going to vote "no."

Most security headers exist to enhance site security. This "security header" seems to exist solely to save site operators the trouble of having to vet what third party resources do (mostly ads I assume).

They seem to want to have their cake and eat it too (i.e. embed toxic content, without vetting it, while also disabling many of the more toxic tricks). Problem with that is that toxic ads pay more BECAUSE they're toxic, that's why you went with that ad network, higher CPM.

How about you just do your job as a site owner and employ an ad network with a code of conduct/morals? Not to mention that this won't work, because real sites actually need some of these features.

There's the fantasy reality we wished we lived in, and there's the pragmatic reality we actually live in, and if you only ever act as though you live in the fantasy reality then the pragmatic reality will always leave you disappointed.

So unless you know of a way to force site operators to act against their best interests to service yours, I would much rather that we at least have this option available.

Also, let's not forget that Google itself has been guilty of letting toxic ads slip through their vetting procedures. It's not as though there's some 100% foolproof way of ensuring that you only ever run ads that are completely benign in every possible sense without doing away with 90% of the things legitimate advertisers demand to have (rich ads, tracking, javascript, etc), so again, unless you've discovered a realistic way for site operators to fund the operation of their sites without having to erect paywalls, the threat of toxic content will always exist.

> So unless you know of a way to force site operators to act against their best interests to service yours, I would much rather that we at least have this option available.

You seem confused about this proposal. This doesn't provide the end user any more options, and isn't meant to.

This is a proposal designed to allow site operators to embed dangerous content without vetting that content. Nothing more, nothing less.

I guess I just prefer to take the optimistic approach to things like this :). I see it as another way for the browser to tell me, a site owner, if something got through that wasn't supposed to. My immediate thought was for better defense against an evil script. Yes, the evil script shouldn't have come up in the first place, but that doesn't mean I'm perfect and an evil script will never make it onto my site.

Aside from disabling misuse of features, it also uses the Reporting API [0] which means that toxic ads violating the feature policy can be reported to the site owner and then potentially removed. That's what I would do if I were a site owner pushing ads -- check on my side to make sure they aren't doing anything questionable and address it immediately if it is.

> How about you just do your job as a site owner and employ an ad network with a code of conduct/morals?

How would this prevent a bad actor from making an ad that looks safe but isn't?

[0] https://w3c.github.io/reporting/

Yes, defense in depth. Do your due diligence, vet what you can, and then lock it down where trust isn't even required. Sites get hacked, whether its CDNs, ad networks, or any other trusted 3rd party.

A great example would be a website with webcam and audio abilities like a conferencing site. You might have 3rd party tools embedded like newrelic or sentry.io for client-side error detection and performance monitoring. Those scripts should NEVER access the webcam or microphone. But what if one of those sites get hacked? Your users have already approved the webcam and mic access to your site, after all its a conferencing tool. But now the hacked sentry script can also link into the webcam and microphone and send that data wherever they like. The client won't see anything different. They approved the access to their microphone and mic already, they won't see anything different. If you used this new header, you have another layer of defense against the hacked scripts. You can define that only scripts from your domains should have access to the microphone and mic, and the browser will deny access to the 3rd party. Beyond that, it also supports reporting, so you can get notifications that newrelic was trying to access users webcams and can enable your incident response team to begin their work responding to the hacked 3rd party.

I actually wish it was the default to have to ask for permission for mic and camera everytime. one extra click doesn't seem overly burdensome to me. I'd even prefer that for native apps.

Feature Policy won't stop scripts embedded in the same browsing context as your page from accessing everything your own first-party scripts can. It's more for restricting iframes and other sandboxed content embedded in your site.

The kind of controls you're describing would difficult to implement, since there are probably dozens of roundabout ways a script could modify the page to trick it into executing code without it being clear that the third-party script is the reason for that code executing. (For example, what if my evil script redefines `console.log`, and then your first-party script calls that?)

The very idea of a sandboxed third-party script running in the same context as first-party code is, IMO, contradictory.

It most definitely will, did you read the article? <origin(s)> allows you to define what script origin have access to what features. The example you bring up where a script modifies the page to do something would require the 'self' origin, which is definitely not secure. I prefer CSP's language for 'self' being called 'self-insecure', because using the 'self' origin isn't secure. Defining the origins of which scripts have access is really the only secure way to lock out a 3rd party.

Well yes, if you prevent even your own site (self) from accessing a feature then obviously third-party scripts running in the same context as your site won't be able to access it either.

Your previous comment however was talking about a situation where your conferencing site needs access to the webcam and mic. In that situation, you _have_ to specify the "self" permission for `camera` and `microphone`, in which case any script embedded in your page (regardless of where you loaded it from) also has access to those features.

I see nothing in the original article suggesting otherwise ('origin' refers to the origin of the browsing context, not the origin the script was loaded from). If the article _does_ say otherwise, then the article is wrong. The Feature Policy spec ( https://www.w3.org/TR/CSP3/ ) refers to "browsing contexts", not "the origin a particular script was loaded from".

I setup a test page for this, and it seems you are right.

Test 1:

    * Feature-Policy "microphone https://example.com"
   
    * Javascript that accesses microphone hosted on example.com
   
    * Everything loaded and worked as expected

Test 2:

   * Feature-Policy "microphone https://example.com"
   
   * Javascript that accesses microphone hosted on 3rd-party.com

   * Everything loaded and worked - not as expected

I definitely didn't understand this new header. I still see how its useful, but not quite as robust as I had expected.

But how do you feel about CSP? This seems analogous, and I don’t think CSP is a bad idea. What’s the difference?

Do you know why do aircraft pilots wear parachutes? So as not to have to use them.

These headers can serve the same purpose: to add an extra layer of prevention, just in case. However well you may vet any 3rd-party content embedded on your pages, you cannot prevent a mistake from their side, at the very least. Let alone any outbreak of malicious code, because 3rd-parties' security is also necessarily imperfect.

A presence of such a layer additionally disincentivizes attempts to add malicious / treacherous content, because it will just not get through.

They say that good security is not like an eggshell, but like an onion.

If I were getting on a plane and saw the pilot was wearing a parachute, I would get right back off.

Airliner pilots don't wear parachutes, and can't jump off.

Military aircraft personnel, and pilots and passengers of very light civil aircraft (think Cessna), do wear them.

</offtopic>

This strikes me as the same kind of thinking as, "We oppose extramarital sex and therefore we should not teach teenagers about condoms, they should just not have sex in the first place and then they won't catch any STIs."

> Not to mention that this won't work, because real sites actually need some of these features.

It works like the CSP header already works, so it's origin-based.

> How about you just do your job as a site owner and employ an ad network with a code of conduct/morals?

And if the ad network suddenly changes their policy without notifying you, what are you supposed to do?

Because you can't proxy the ad network (because then the ad network doesn't know which ads to serve, since they lose info on the origin request) there are two ways to deal with this: either continuously monitor your third party providers for malfeasance, or sandbox them. Isn't a sandbox better?

> And if the ad network suddenly changes their policy without notifying you, what are you supposed to do?

That's a legal question, not a technical one.

If another company violates your contract with them, or the contract doesn't require notification for substantial contractual changes then you need to talk to your lawyers.

> That's a legal question, not a technical one.

So we should just, what, pass a law that it's illegal to listen to traffic if you're not law enforcement with a warrant, and then we don't have to encrypt any of our traffic anymore?

Who needs technical solutions when we have legal ones?

(internet-required-explicit-sarcasm-notice)

You're being ridiculous. This is like saying we shouldn't have a permissions system on mobile devices because that's just a way to save lazy users the trouble of having to vet what the app they just installed actually does.

This isn't proposing user permissions, this is proposing site permissions.

A better analogy would be, that app developers are too apathetic to review their own app's permissions, so they want a way to limit what permissions a third party ad library could add to their app.

It is a way for people shirking responsibility for their own site, app, or content.

It doesn't matter who the permissions are for, the principle is the same.

_Should_ users perform a through investigation of every app they install, checking that it does exactly what they expect and no more? Perhaps; but that's not really practical.

The same applies for developers. Should these sites review the source code of every ad they embed in an iframe, whitelisting each ad individually? Maybe, but that's not going to happen. The other commenters are right, what you're suggesting is fantasy, not pragmatic reality.

Permissions systems are better, because they prevent misbehavior even when manual review fails.

> It doesn't matter who the permissions are for, the principle is the same.

It absolutely matters.

Users should have minimal responsibility while consuming content. Site owners should have major responsibility while providing content.

> Should these sites review the source code of every ad they embed in an iframe, whitelisting each ad individually?

They absolutely should know who their ad platform is, what their policies are, and what is/isn't acceptable for an ad hosted by that platform. If their ad platform falls short, they should shop around for a better alternative.

> They absolutely should know who their ad platform is, what their policies are, and what is/isn't acceptable for an ad hosted by that platform. If their ad platform falls short, they should shop around for a better alternative.

... Or you could choose a wholesome ad network (if such a thing exists), AND limit what features they can access just in case something goes awry and a malicious ad somehow makes it through.

> If their ad platform falls short, they should shop around for a better alternative.

That's like suggesting users not use the app store anymore because sometimes malware slips through the review process.

All major ad networks will occasionally have ads which violate their written policies. Google, for example, bans millions of ads every year for that reason ( https://www.blog.google/technology/ads/how-we-fought-bad-ads... ). The solution to that isn't to just ditch those ad platforms entirely.

The solution is to block all ads until site owners start to take responsibility.

As a user I couldn't care less about the hardships of the site owner.

What utter nonsense.

Do you give every user and process on your machine root access? After all, if you trust them, then why restrict them? And if you don't trust them, why let them login / execute at all?

In reality, trust can only ever be partial, and even honest actors can cause damage accidentally, or can be compromised by 3rd parties through no fault of their own. Permissions are how you overcome partial trust: You grant actors only those permissions to act in ways related to the task you want them to do. That way, if even if they are dishonest or compromised, the damage they can do is limited. This principle is the cornerstone of modern security. It's the only way that most systems can interact at all.

It is isn't "apathetic" for apps or websites to restrict the permissions of ads. It's apathetic not to. It's the same apathy that causes users to click through warning screens and grant apps whatever permissions they want, even when a Sudoku game is requesting access to their microphone and camera.

There are uses for this besides ads.

When I worked on Google Reader, something like this would have been incredibly useful. At the time, the only truly safe way to handle embed/object/iframe in post content was to completely filter it out. That's pretty terrible for usability, though. We ended up having a exceptions in our HTML sanitizer embeds of content from certain sites (eg: elves of popular video sites like YouTube and Vimeo were allowed).

I always hated that solution because it made us vulnerable to any site in the whitelist (whether because they become malicious, or because they themselves have a vulnerability), it was unfair to smaller/newer sites, and it was a additional maintenance burden.

The fact that you have to tell the browser not to do stuff that other sites you're also telling it to load are telling it to do is perhaps exemplary that the web as we know it has taken a wrong turn somewhere

Surely this header should be an allow list, not a block list? Disable features from iframes etc. until permitted, if the header's present, so that you never end up with unexpected activity from external sources.

Unfortunately, reverse compatibility forces the web into a blacklisting model with new headers.

In my Copious Free Time (TM) I am trying to write a web framework that is default deny instead, so even if the web itself is whitelist based, you can try to write in a default-deny environment for security reasons. But even if imagine a perfect such framework from 2017, now in 2018 you have these new headers to deal with, and it means even if the 2018 version of this default-deny framework comes up, you can't just upgrade the framework itself and do nothing because now if you default-deny all of these the website stops working. Plus it's a sense of false security if you program this restriction that says "no iframes!" if someone uses a browser that doesn't support it.

It's a hard problem, unfortunately.

Couldn't we instead have a header sites could implement to indicate they're compatible with the newer security model? The incentive would be that new features can only be accessed by sites that conform to the new model.

Older sites could continue to function as they do today or perhaps be even more heavily sandboxed AND not have access to new APIs.

Permissive by default also means you have to worry about making sure that every time a new feature comes out that you have to go back and update your code to disallow it rather than updating it to be allowed only if and when you actually want to use it.

I also wonder if this will lead bad actors to scan for this header and start targeting their ads at sites that don't have this policy configured.

It really does seem incredibly poorly thought out.

If it were an allow list, then they wouldn't be able to add more features to the list without breaking backwards compatibility.

For example, imagine your site relies on document.write to function, and there's currently no feature policy that lets you whitelist that feature. You create a whitelist that includes the features you do use, but that list doesn't mention document.write, because there's currently no way to block or allow that with a feature policy. Now imagine Chrome adds a feature policy for document.write six months later; your site will break because you didn't explicitly whitelist document.write, even though that would have been impossible for you to do at the time your site was first created.

Devil's advocate: If your site is doing something that is worth adding a secturiy flag for, and is unmaintained, it should break.

Such as... playing audio?

These "security flags" could be added for almost anything that might annoy a user; it's not just for security.

> Such as... playing audio?

Yes, if it's playing audio not initiated by the user.

> These "security flags" could be added for almost anything that might annoy a user; it's not just for security.

Good. I'm a user and I don't like being annoyed. It's… annoying.

Quoting an opinion by someone other than myself (https://groups.google.com/a/chromium.org/forum/#!msg/blink-d...) regarding the termination of HPKP which is relevant to Feature Policy:

> If you going to take the same approach moving forward then I will simply ignore anything invented by google/chrome, if I realise that after 2 years it will probably be dead due to lack of adoption, waste of my time to invest in anything that has a 2 year shelf life.

Feature Policy is a tool which, though I value, I don't see high hopes for because of the precedent set with HPKP. I'm on the fence with implementation solely because Google's unwillingness to invest in the success of their development platforms is now adversely impacting their security team.

And that breaks my heart.

https://wicg.github.io/feature-policy/

All these security headers seem like a terrible idea to me, shouldn't security be the default - especially if it breaks insecure websites?

Good idea, let's break 90% of the internet and see why nobody uses your secure by default browser.

You're not wrong, but what you want doesn't work for human reasons.

This is true most of the time, but if it's necessary to keep the ads flowing, I think most ad-supported sites will update very quickly.

I understand your sentiment but I do wonder what the extent would actually be. The largest website are more than capable of adapting, and older sites are more likely to either not use any JavaScript or only accept http traffic (which is already a lost cause). I suppose the ones would take the biggest hit would be the people running WordPress blogs with various (already insecure) site plugins.

Suppose if these security changes would slowly get imposed over all https traffic in a coordinated fashion among the major browser vendors over a large time span? https requires some periodic maintenance anyway, so it shouldn't add an unreasonable workload.

I worry that this isn't happening because the ad industry (including Google) doesn't want to take responsibility over distributing untrustworthy and insecure code.

Think of these headers not so much as security. Just because a site doesn't have this or other headers doesn't make it any less secure. The headers are better described as fine-tuned access-control policies. You want to be able to send your users notifications on your site? Well great, now any ads on your site have the same ability. These headers allow you to control that. The primary site has features x,y, and z - but any ads or iframes don't have any features.

> distributing untrustworthy and insecure code.

So this isn't really how things are, we didn't have the ability to fine-tune these access control features before. Either you accepted a website as a whole to give you notifications or not. On the client side it still appears the same, but on the server side they can limit which scripts/domains actually get those permissions.

I suspect this is to help websites crack down on crappy ad networks without actually having to moderate their ads?

Some would say the fact websites are unable to control what they serve is why ad blockers are so popular.

Won't they just add "allow=all,the,crap,they,want" in the embed iframe code they ask site owners to copy/paste?

I'm sure there's a reason for the design (allowing deny all at the top and then only allowing what's specifically needed is nice), but I'm not sure what it'll actually do for the case where an iframe is just a copy/paste embed and can use the allow attribute for whatever it wants.

> Feature Policy is being created to allow site owners to enable and disable certain web platform features on their own pages and those they embed.

I think this needs to be rephrased. The site/page shouldn't be deciding what features it can use, it should be indicating what features I might ask permission to use.

I can see the benefit of saying "I might ask to vibrate or use your location but deny any other requests" but this should only be used as a whitelist in the sense that those are the features that the users should be asked for permission to use.

I'm not sure I'd call this a security header, as all of the features controlled by feature policy already have their own systems in place for ensuring they don't hurt user security. A site can't get your GPS location without asking your permission, regardless of what a site's security headers say.

Rather, this seems more like an anti-annoyance header; it lets sites and server administrators restrict the behavior of content they're serving to ensure it doesn't annoy the user. The most obvious use case is for ads: a site could, for example, specify that ads are _not_ allowed to play audio; and the user agent would enforce that.

Spec draft: https://wicg.github.io/feature-policy/

Not sure how relevant such detailed settings really are... Could be a tool for site operators to somewhat limit issues with bad ads getting through?

That's a very HTML specific HTTP header and it seems very out of place.

There are already tons of HTML specific HTTP headers (Link, CSP, X-Frame-Options, etc.). I don’t see why HTTP headers shouldn’t be used for metadata when serving HTML, it’s not like the header needs to be added to the HTTP spec.

I think this would look better as some kind of <meta> tag inside the HTML document.

I think that the document itself should have knowledge about its security requirements (the "allow" field in <iframe> tags requires this), so it seems awkward to have part of the responsibility in the HTTP server and another part in the HTML document.

As a website operator, I should be able to have some guarantees about the security of my site without auditing every single piece of HTML, JavaScript, and CSS. That might be far from a trivial task if my site has user-generated content... beyond forums, there are also blogs and CMSs. HTML, JS, and CSS are fast moving targets and something that is safe today could easily have security implications down the road when a new feature arrives. This has happened before and it will happen again.

Link is not HTML specific. Content-Security-Policy can also be specified as an HTML meta tag, that's where it belongs. CSP obsoletes X-Frame-Options which couldn't be specified as a meta tag only because MS made up that rule when they made up the header, with no justification for it. Everyone followed suit simply because that's what people had to do when MS had a stranglehold on the internet.

I'm sure there are other examples of HTML specific HTTP headers that can't be specified as meta tags because we're still stuck with a lot of crud, but that doesn't mean they're not out of place too. It's just the wrong layer for that data.

The CSP info is a little off. Specifically, there are some directives of CSP (in this case frame-ancestors, the replacement for X-Frame-Options) that are specifically ignored if specified in a only <meta> tag. The header is the only way to have access the full set of CSP features.

I see that. I couldn't find any justification for that choice either. Any reason I can think of (security, legacy, optimization) would imply the powers that be wouldn't want CSP allowed as a meta tag either. My guess is it's just another bad choice.

I've had iframes completely disabled in uBlock Origin for years now and the only time I've found it "breaking" ("fixing" from my perspective) things is when sites do something like third-party run sweepstakes. I think we'd be better off just breaking iframes now for the sake of our children, like we did with Flash et al. Start off with "click to activate iframe" with harsh warnings, then completely remove support shortly after. There are better solutions for sites that are using it for legit reasons.

What exactly do you think HTTP stands for?

I'll give you a hint: both HTML and HTTP share an HT.

Hold on, does that mean that a web site is allowed to vibrate my phone? Since when and who agreed to that idiocy?

Navigator.vibrate() [0] is available in Firefox since January 2012, according to Can I Use data [1].

Here is the initial Bugzilla issue: https://bugzilla.mozilla.org/show_bug.cgi?id=679966

[0]: https://developer.mozilla.org/en-US/docs/Web/API/Navigator/v...

[1]: https://caniuse.com/#feat=vibration

Oh damn. And I like how Firefox for mobile handles tabs.

"vibrate"

Is this supposed to mean "notify"?

Also [1] doesn't return the most ideal results.

[1] https://www.google.com/search?q=site%3Asecurityheaders.com+v...

« To further the exposure of the header I will be adding detection to Security Headers. The header will not have a weight to impact the grade but it will be flagged as required. I can start to track utilisation and make people aware of its existence to drive adoption! »

That seems really quite early. Give it some time, let people discuss it.

No, just no. It’s already hard enough to view source, save a video, or download a picture. Unless users have full ultimate control, this reminds me of DRM.

Reply on news.ycombinator.com