
A new security header: Feature Policy - detaro
https://scotthelme.co.uk/a-new-security-header-feature-policy/
======
Someone1234
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.

~~~
dqv
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/](https://w3c.github.io/reporting/)

~~~
move-on-by
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.

~~~
Ajedi32
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.

~~~
move-on-by
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.

~~~
Ajedi32
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/](https://www.w3.org/TR/CSP3/) ) refers to
"browsing contexts", not "the origin a particular script was loaded from".

~~~
move-on-by
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.

------
inetknght
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

------
james_a_craig
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.

~~~
jerf
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.

~~~
cptskippy
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.

------
eganist
Quoting an opinion by someone _other than myself_
([https://groups.google.com/a/chromium.org/forum/#!msg/blink-d...](https://groups.google.com/a/chromium.org/forum/#!msg/blink-
dev/he9tr7p3rZ8/S5B9ImLuBAAJ)) 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/](https://wicg.github.io/feature-
policy/)

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

~~~
pixl97
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.

~~~
daxterspeed
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.

~~~
move-on-by
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.

------
cptskippy
> 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.

------
Ajedi32
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.

------
detaro
Spec draft: [https://wicg.github.io/feature-
policy/](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?

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

~~~
johncolanduoni
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.

~~~
JD557
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.

~~~
klodolph
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.

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

~~~
esnard
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](https://bugzilla.mozilla.org/show_bug.cgi?id=679966)

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

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

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

------
kevin_thibedeau
"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...](https://www.google.com/search?q=site%3Asecurityheaders.com+vibrate)

------
phyzome
« 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.

------
natch
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.

