HTML Imports and CSP

Hi all. We, on Chrome, have recently started running into HTML Imports vs
CSP in several contexts, so I thought I'd bring up (again) the issue of how
CSP should interact with HTML Imports. Now, at least in Chrome, documents
that are imported are controlled by the policy of the page. This leads to
problems where, for example, an imported document has an inline script, but
the page's policy disallows them, and it's preventing real applications
from using CSP. To complicate things further, we also have very real
concerns about content injection problems with HTML importable widgets
themselves.

After several internal discussions, we've come up with a laundry list of
potential options for imports and CSP. None of these are complete solutions
on their own, many of them are strawmen/not workable in their immediate
form, and some are just wishful thinking (such as the "strict-by-default"
suggestion). I'll mention my personal thoughts below.

   1. Create a new CSP directive for sources that can be imported.
   2. Allow imports if the document is on the importing page's script-src
   whitelist.
   3. Imported documents can provide their own, independent CSP that is
   applicable within the import only (and *not* transitively into documents
   *it* imports).
   4. Have a strict-by-default policy for imported documents that are
   always enforced (e.g. inline scripts are never allowed in HTML imports).
   5. Pass a script nonce to imports and allow them to inline only with
   that nonce.
   6. Have a CSP subdirective that controls what imports can do, somewhat
   like the iframe sandbox directive, such as if inline scripts are allowed.
   7. Have a CSP directive that specifies what other
   directive imports should be treated as (e.g. "apply img-src policy to
   imports").
   8. Isolate docs so all of this is a non-issue, i.e. execute scripts in
   imported docs in their own execution context.

Personally, I think a combination of (1 or 2), (3), and (6) would be the
best solution. I think that gives us:
(1 or 2): high level control of what can be imported
(3): Control over the actual contents of the imported document, but in a
way that only the creator of the document can possibly enumerate
(6): External control over a few "important" properties that the top-level
origin may want to enforce.

Also, I think another possibility is using one of these options in the
short term (e.g. use the outer page's script-src to allow imports), and go
with other options in the long term.

Thanks for reading this far :-) Looking forward to hearing your thoughts!
--Joel