Re: HTML Imports and CSP

After thinking about this a bit more over the holidays, I think I'm more in
agreement with you than I thought, Dev. :)

What do you think about this:

1. Move imports to `import-src` (we'll need to measure usage in Chrome, but
assuming this is mostly an extension thing at this point, it should be
doable).

2. Give imports their own policy (that is, no longer inherit from the
containing document) like Workers and frames, which would enable them to
either whitelist `unsafe-inline` themselves, or use nonces/hashes whatever.

-mike

--
Mike West <mkwst@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

On Sat, Apr 4, 2015 at 6:23 AM, Devdatta Akhawe <dev.akhawe@gmail.com>
wrote:

> > You're not wrong there; inline event handlers are bad and they should
> feel
> > bad.
> >
> > That said, is the risk really different in kind from just allowing plain
> old
> > inline script that executes directly? It doesn't seem to be. Allowing one
> > without allowing the other seems capricious.
>
> I think Brad put the concern really well, but even for code written by
> developers I know---I would rather trust their ability to sanitize a
> string inside a JS variable than inside a script tag than "inside JS,
> inside an event handler, in response to a DOM event". And I would
> trust a review of the former more than a review of the latter.
>
> > What's your ideal solution?
>
> I tend to agree with Crispin on code data separation. Anything that
> mixes the two should have the word unsafe in it.
>
> If not that, then just inline scripts will make me less sad. Allowing
> inline scripts and event handlers just because the import is allowed
> in script-src is definitely something I would strongly oppose.
>
> -Dev
>