Comment by dqv | Hacker News Reader

Comment by dqv | Hacker News Reader

Parent Full thread

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.

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.

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.

Reply on news.ycombinator.com