4 ms·

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 ne

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.

greggman 8y ago
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.
Ajedi32 8y ago
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 8y ago
  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 8y ago
    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 8y ago
      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.

greggman 8y ago

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.

Ajedi32 8y ago

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 8y ago
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 8y ago
  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 8y ago
    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.