unsafe-eval and WebAssembly

[fgmccabe]

In chrome, there is an implemented extension to unsafe-eval that allows execution of WebAssembly to be governed by this source keyword.
We are currently progressing (?) a revision to CSP that uses a slightly different keyword: wasm-unsafe-eval to govern WebAssembly. The primary motivation for having a separate keyword is to permit authors to allow WebAssembly but disallow JavaScript eval.
However, there remains the issue of what to do about unsafe-eval after this is adopted. This is a question since, as far as I understand, neither Firefox nor Safari implements the unsafe-eval feature for WebAssembly.

There are two choices that I can see:

1. Do not specify any extension to unsafe-eval to apply to WebAssembly in the CSP spec.

This would leave chrome in the situation of having to eventually deprecate its handling of unsafe-eval in favor of the wasm-unsafe-eval keyword.
Note that chrome must also deprecate its handling of the wasm-eval keyword which is used only for chrome extensions at this point.

2. Augment the spec to also refer to unsafe-eval as an 'alternative' to wasm-unsafe-eval.

This would require Firefox, Safari and all the other browsers to replicate the somewhat complicated situation currently present in chrome.

This issue is intended to start a discussion on this topic. But, I do have an opinion:

I believe that option #1 is likely the best way of avoiding unnecessary crud in the specification and in implementations.

However, option #2 is actually the easiest for chrome to implement (since it reflects the current situation).

[shhnjk]

I prefer option 2.
I think it's not much of a difference in terms of Chromium implementation to support option 1 (just stop checking 'unsafe-eval' for WASM and instead check 'wasm-unsafe-eval'), but it would be a breaking change for all existing websites that uses WASM with CSP.

[annevk]

Yeah, I always saw unsafe-eval as a superset and not necessarily specific to JavaScript.

[fgmccabe]

Closing this with the resolution to adopt option #2.