Contact emails
andy...@chromium.org, mk...@chromium.org
Spec
https://w3c.github.io/webappsec-csp/embedded/
Summary
CSP's Embedded enforcement defines a mechanism by which a web page can embed a nested browsing context if and only if it agrees to enforce a particular set of restrictions upon itself. In other words, an embedder can pull in a third-party widget via code like the following, to ensure that it doesn't load plugin content, or resources from unapproved origins:
<iframe src="https://cool-widget.example.com/"
csp="default-src approved.cdn.com; object-src 'none'">
</iframe>
The embedee is informed about the embedder's requirements via a new HTTP request header, and can opt-in by reflecting in the `Content-Security-Policy` header a policy that is at least as strong as the one specified or by returning an appropriate `Allow-CSP-From` header.
If neither is done, the response is blocked.
Motivation
Content Security Policy defines ways for developers to restrict their web pages to trusted content. However, there isn’t any enforcement done on embeddee’s such as third-party advertisements and widgets to abide by embedder’s policies.
Interoperability risk
Firefox: No public signals
Edge: No public signals
Safari: No public signals
Web developers: Tentative interest
We've talked about this feature a little bit in the WebAppSec working group, and folks are generally positive about the behavior it enables.
There has been tentative interest expressed by developers around this feature.
Compatibility risk
Low. Existing content that doesn't use the `csp` attribute won't be affected at all.
Ongoing technical constraints
None.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux,
Chrome OS, Android, and Android WebView)?
Contact emails
andy...@chromium.org, mk...@chromium.org
Spec
https://w3c.github.io/webappsec-csp/embedded/
Summary
CSP's Embedded enforcement defines a mechanism by which a web page can embed a nested browsing context if and only if it agrees to enforce a particular set of restrictions upon itself. In other words, an embedder can pull in a third-party widget via code like the following, to ensure that it doesn't load plugin content, or resources from unapproved origins:<iframe src="https://cool-widget.example.com/"
csp="default-src approved.cdn.com; object-src 'none'">
</iframe>
The embedee is informed about the embedder's requirements via a new HTTP request header, and can opt-in by reflecting in the `Content-Security-Policy` header a policy that is at least as strong as the one specified or by returning an appropriate `Allow-CSP-From` header.
If neither is done, the response is blocked.
Motivation
Content Security Policy defines ways for developers to restrict their web pages to trusted content. However, there isn’t any enforcement done on embeddee’s such as third-party advertisements and widgets to abide by embedder’s policies.
Interoperability risk
Firefox: No public signals
Edge: No public signals
Safari: No public signals
Web developers: Tentative interestWe've talked about this feature a little bit in the WebAppSec working group, and folks are generally positive about the behavior it enables.
There has been tentative interest expressed by developers around this feature.
Compatibility risk
Low. Existing content that doesn't use the `csp` attribute won't be affected at all.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DdvWs2SBUSWinex6mob5LAr0r2Dr1TZycDXd%3DbsamzQpA%40mail.gmail.com.
Looks like this didn't go through TAG review, and now it's too late to block on it, but have CSP things generally gone to the TAG?
There's just a tiny bit of IDL for this feature, but I took a look. As implemented, the csp attribute is simply reflected, but the spec says some more elaborate things. Which should change?
There's also a bunch of "upstream this" FIXMEs in the spec, is that underway?
On Thu, Jun 1, 2017 at 1:44 PM, Philip Jägenstedt <foo...@chromium.org> wrote:Looks like this didn't go through TAG review, and now it's too late to block on it, but have CSP things generally gone to the TAG?Hrm. I thought we talked about embedded enforcement as part of https://github.com/w3ctag/design-reviews/issues/42, but looking at the notes, I think you're right that it didn't come up. :(
There's just a tiny bit of IDL for this feature, but I took a look. As implemented, the csp attribute is simply reflected, but the spec says some more elaborate things. Which should change?It should just be reflecting. We moved the policy validation to block setting the `Sec-Required-CSP` request header, but I apparently missed cleaning up the attribute integration. The tests look correct, though, so I think it's just an oversight in the spec.
There's also a bunch of "upstream this" FIXMEs in the spec, is that underway?I haven't started pushing patches upstream to HTML and Fetch. Anne has generally been reticent to land those patches when there wasn't clear implementation intent from more than one browser. *shrug* If you'd like me to queue up patches that we can rebase when other vendors hop on board more actively, I'm happy to start that process.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYfjCeAW7%2BcXYvC3ScdHCPgr%3DyiN4HVx0Lg0gWFrL%2BR8cw%40mail.gmail.com.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_0am%3DbnC3fmMYyfNV5UvFWO9%2BA1hN%3DwzwbtK%2Bjmn%3Dk8Q%40mail.gmail.com.