This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Import should beware Content Security Policy [1] There are at least two questions to adopt CSP for HTML Improts: - Q1: Which directive should it follow or should it have its own directive? - Q2: Which document should sub-imports restricted? The master, or the parent? For Q1: It should be script-src. It runs script and it isn't rendered. Having its own directive could be an option. but I don't come up with a valid scenario where the author wants such one. For Q2: It should follow master's policy, not parent's This is because the script runs on the master's scripting context. [1] http://www.w3.org/TR/CSP/
As discussed at https://codereview.chromium.org/19940002/, > For Q2: > It should follow master's policy, not parent's > This is because the script runs on the master's scripting context. I was convinced that Each import should respect its own CSP, rather than one of the master. The rationale is that: - It is confusing when the document behaves differently when it is loaded as import and it is loaded as usual (as a frame). Such parity should be minimized. - If the master want protect itself, it should just block imports being loaded.
Noticed that it's hard to enforce non-eval() policy because imports share its context with the master. V8/Blink doesn't have mechanism to switch allow/disallow eval per script evaluation. Also, it's hard to track the call site if we call eval in some callbacks. In practice though, this won't be a problem because apps/sites which want to prohibit eval() in imports will want to prohibit eval() in its own context. So question here is whether we should explicitly exclude eval() blocking or leave it as an implementation limitation.
CSP1.1 has HTML Imports built-in https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html#script-src
https://dvcs.w3.org/hg/webcomponents/rev/fe810409723a