Figure out if we need 'trusted-script' in script-src

[koto]

trusted-script keyword is used now for javascript: navigations and eval guarding. Since we've integrated with CSP logic, perhaps the keyword is now superfluous?

If a website uses eval or javacsript: and it uses script-src, it needs to set appropriate unsafe-* keywords anyhow, for browsers with no trusted-types support.

We are close to having working downgrades. See #218 for a working downgrade-to-string for eval; for javascript: navigation, the default policy will simply not be created, and therefore called.

It seems like a combination of script-src ... 'unsafe-inline' 'unsafe-eval'; trusted-types ... correctly limits the unsafe behavior to Trusted Types, with a working downgrade to string for non-supporting browsers. IOW, trusted-types directive adds additional restrictions independent of script-src, which seems to be not violating CSP principles, and is conceptually simpler.

cc @mikesamuel @mikewest

[koto]

/cc @mikewest , Do you have an opinion here? Essentially, it all boils down to whether trusted-types directive (and a JS code conforming to it) should be able to bypass existing restrictions in script-src, or would we require a new keyword in script-src as well.

[koto]

Pingy ping @mikewest

[mikewest]

I think you're right that script-src 'trusted-script' ...; trusted-types name is less backwards-compatible than script-src 'unsafe-eval' ...; trusted-types name. I think I'm comfortable treating trusted-types name as an attenuation of 'unsafe-eval' without a separate keyword.

[lukewarlow]

I'm reopening this issue to restart this conversation. I think something that's been missed in previous considerations is that some use cases might care more about security than compatability.

think you're right that script-src 'trusted-script' ...; trusted-types name is less backwards-compatible than script-src 'unsafe-eval' ...; trusted-types name

This lack of backwards compatability is a desired characterstic. Currently to use eval in TT envs you have to add a keyword that means browsers without TT allow you full unmitigated eval. Which is not always desirable.

If we added a new trusted-script (or trusted-eval or some other name) keyword then that would allow you access to eval where supported and degrade to smaller feature set where it's not provided.

[caridy]

@lukewarlow thanks for reopening this. we certainly need this resolved to be able to move forward with the regulations in Europe.

cc @gregwhitworth

[lukewarlow]

As part of #464 - we get the raw arguments to eval and new Function() so we can ensure they are trusted types which would make this easier

[annevk]

A worry I have here is that with Trusted Types the definition of trust lies with the website. And while I suppose a website could always bypass its own policies (e.g., to bypass unsafe-eval you could have a <script src> proxy of sorts I think) this seems easier with Trusted Types (have a no-op policy).

In particular because regulation around security policies might encourage perverse incentives.

[caridy]

@annevk I think the main incentive here is to prevent evaluation in browsers without TT, as this constitutes a security problem today with no way to mitigate it without introducing UA sniffing.

[lukewarlow]

Closing this to focus discussions in w3c/webappsec-csp#665