Re: HTML Imports vs unsafe-inline

On Thu, Sep 11, 2014 at 8:23 PM, Jeffrey Yasskin <jyasskin@google.com>
wrote:

> 'unsafe-static-inline' does look like it'd work.
>

I agree. I guess I'm wondering whether it needs to be part of the
specification, or whether it could be something that individual browsers
implement as part of their extension systems. I don't know of a good use
case for 'unsafe-static-inline' on the web (though that might change if
some of these packaging specs get implemented), but it's clearly useful for
the proprietary Chrome Apps and FirefoxOS apps scenario. Perhaps we could
ask those platforms to experiment with such a directive and report back to
the group with their implementation experiences?

Re the concern about developers shooting themselves in the foot, I
> think 'unsafe-static-inline' would be an improvement over the current
> situation. Right now, developers who run into the inline-script
> prohibition can add 'unsafe-inline', opening themselves up to DOM
> attacks too, or they can add a hash or nonce. Ironically, a hash or
> nonce is _easier_ to produce for a dynamic script containing a
> server-side XSS than for a static script since there's already code
> running over the dynamic script. It'd be nice to make static scripts
> just as easy to whitelist.
>

Hardcoded inline script in a static document is (IMO) best dealt with via
whitelisted hashes, not a nonce. Hashes are easy to produce for static
inline script.

Re Joel's point (https://crbug.com/393307#c15) that developers could
> just live with an extra reload of the app/site for each change to the
> javascript, I think it's clear why that would be unfortunate.
>

I agree that it would be good to find a mechanism that allowed developers
to develop quickly. I'm not sure that means that no tooling is allowed,
however: I've certainly developed exciting and dynamic websites with
scripts that watched directories for changes and rebuilt dynamically, for
instance. That's not at all uncommon.

-mike