3 ms·
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
by 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 agoI 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.