Finalize the integrations that guard eval & Function.constructor

[koto]

Essentially, we'd like:

1. eval(TrustedScript), new Function(TrustedScript), and new Function(TrustedScript, TrustedScript) to work
2. Their string equivalents to go through the default policy createScript function (a.k.a. if TT are enforced, to generate violation and not execute code by default)
3. The default policy to be able to change the values to be executed.

The language primitives tracked in Dynamic Code Branch Checks TC39 proposal.

There's additional CSP integration required, tracked #143. Since it relaxes the CSP conditions, we might require a new keyword. We propose script-src 'trusted-script'

[koto]

The Blink/V8 implementation already has the behavior above. The ECMAScript bits are progressing through TC39.

[koto]

Note: change the spec text once https://github.com/tc39/proposal-dynamic-code-brand-checks stabilizes. It will likely require adding a slot to TrustedScript and adjusting for the new host callout signature - in CSP ( https://w3c.github.io/webappsec-trusted-types/dist/spec/#csp-eval) and HTML.

[caridy]

There's additional CSP integration required, tracked #143. Since it relaxes the CSP conditions, we might require a new keyword. We propose script-src 'trusted-script'

@koto can you link to the issue tracking the addition of the new keyword script-src 'trusted-script'? We will like to see that done sooner rather than later considering the imminent enforcing of the regulations in Europe.

[koto]

The CSP integration would need dynamic-code-brand-checks proposal in ES - that got blocked from advancing to Stage 2 in TC39 (relevant discussion), so it's unlikely this would be specified in CSP soon.

[caridy]

@koto we got consensus around tc39/ecma262#3222 last week, which I think is related. Now the host hook has access to the value. And we are still pending to figure what to do with tc39/ecma262#1498 (comment), do you see a path forward there to get this issue folded into it?

[koto]

Based on tc39/ecma262#3222 (comment), the intention changed during the plenary and the host only has access to the stringified value. The meeting notes are not public yet, but I guess the crucial point would be to understand what concerns caused to reintroduce stringifying, because it seemed like the original intention of tc39/ecma262#3222 was to supersede tc39/ecma262#1498.

[nicolo-ribaudo]

@koto The motivation for that ECMA-262 PR is to allow the unsafe-hashes CSP to also be used for eval and new Function, other than just for executing code in inline script tags and inline event handlers. It ended up being a change independent from trusted types support.

[koto]

Thanks for context. Do you know what caused the change during the plenary? What were there concerns to give host the unstringified value?

[nicolo-ribaudo]

Yes. The plenary change was motivated by the desire to expose the string to the host so that CSP's unsafe-hashes policy could be extended to work with eval/new Function. Passing the object as-is doesn't work for this case, because the host would need to stringify the object (which would thus be stringified twice).

My idea is that the hook can still be passed the objects (and it should, for TT, there is no other way), but it can simply receive both the objects and the strings.