Re: About script-nonce

Hi David,

Yes, if 'unsafe-eval' is enabled, then it's perfectly possible to emulate
'script-nonce' on current pages by evaluating the content of script blocks
that were otherwise blocked. There would be a bit of difficulty around
delivering the random nonce safely to JavaScript, but I'm sure some clever
mechanism could be worked out.

Regarding the loader API, what questions do you have specifically? I'm not
familiar with the details of the proposal, but based on a quick glance, it
appears that  we would want to govern 'Loader.prototype.eval' and
'Loader.prototype.evalAsync' under the same rules as 'eval', and govern the
fetching semantics under the same rules as 'script-src' matching.

In general, I'd say that if it loads something over the network or directly
executes plaintext, the same rules should apply.


Mike West <>, Developer Advocate
Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Google+:, Twitter: @mikewest, Cell: +49 162 10 255 91

On Tue, Mar 5, 2013 at 8:24 PM, David Bruant <> wrote:

> Hi,
> I feel that the kind of use cases script-nonce enables ("strictly specify
> exactly which script elements on a page were intentionally included for
> execution") could be accomplished by doing the following:
> 1) Send CSP directive with script-src forbidding inline scripts (but
> allowing unsafe-eval)
> 2) Send some inline <script>s in the HTML anyway but identify the trusted
> ones by a given id/class/data/type attribute (possibly randomly generated)
> 3) Have some code that reads HTMLScriptElements.textContent and eval it.
> "eval it" here could also mean using the ES6 Loader API [1].
> Which gets me wondering, how will CSP/unsafe-eval interact with the ES6
> Loader API?
> David
> [1]**doku.php?id=harmony:module_**loaders<>

Received on Monday, 18 March 2013 10:55:56 UTC