I've put together a quick example here: https://s3.amazonaws.com/webassembly-chrome-csp/csp_test.html

I think the goal was for user-agents to become consistent in how they interpret unsafe-eval and wasm-eval directives. Issue #1 discussed how not to, and issue #2 touches on how to, but I'm not sure if consensus has been reached.

Right now Chrome restricts 'wasm-eval' to web apps because it's not part of the CSP standard. I'm going to try to put together a PR this week to move along the process of making 'wasm-eval' standard, at which point it should be pretty straightforward for Chrome to expose 'wasm-eval' to the web.

Awesome.

Out of curiosity, I just tried running your test case on Safari and got:

[Error] TypeError: WebAssembly.instantiateStreaming is not a function. (In 'WebAssembly.instantiateStreaming(fetch('simple.wasm'), importObject)', 'WebAssembly.instantiateStreaming' is undefined)
	Global Code (csp_test.js:3)

Does that match what you see? Based on the table on the Wasm CSP Proposal, Safari should not allow instantiate or instantiateStreaming without 'unsafe-eval'.

Safari currently doesn't implement streaming.

I just submitted the PR for 'wasm-eval': w3c/webappsec-csp#293

Has there been any movement on this? Looks like the PR has been open for over 4 months now.

The CSP proposal stalled out as @eholk has moved on to another team. However, @titzer is starting to help out now.

Awesome, thanks for pushing this forward.

So just for the sake of clarity, the end goal here will be to create a CSP that allows WASM without allowing unsafe-eval of everything? I'm also looking at incorporating WebAssembly into my application and ran into this issue, so was hoping unsafe-eval wasn't the only way out.

Also, unrelated question: why do I not receive this warning on Firefox?

@twilco Yes, the proposed wasm-eval (or maybe unsafe-wasm-eval) would be a separate directive that enables WASM code generation independent of JavaScript's eval.

There's a PR #17 to rename the directive. However, for Chrome apps that use extension URLs, we'll likely keep the old directive for some transition time.

So has wasm-unsafe-eval been implemented in chrome and in which version ?

Hi, we've only implemented wasm-eval (preliminary name) in Chrome for extension URLs. The new name wasm-unsafe-eval (and applying to all URLs) has not yet been implemented. Given that this proposal seems to be (slowly) iterating to a decent state, I think we can begin implementation soon.

Either treating the Response object as an origin according to the given CSP

I wish to be able to use WebAssembly from my extension -- this is already the case for the Firefox version of the extension.

However, I do not plan to use wasm-unsafe-eval if/when it becomes available, as this goes against the spirit of not executing remote code.

What is the reason Chromium can't allow loading of wasm modules from same-origin Response objects? This would solve the issue of loading/executing only same-origin wasm code (i.e. the extension's packaged files) without having to resort to relaxing the default CSP in the manifest.

I opened a bug on the Chromium bug tracker for implementing wasm-unsafe-eval: https://bugs.chromium.org/p/chromium/issues/detail?id=948834&can=1&q=wasm-eval Please star it if you're interested in following updates.

I've filed Support origins and SRI-style hashes in CSP for WebAssembly streaming APIs to address the concerns of @gorhill and myself.

Hi there - @hackcasual - I am running into this error when attempting to embed Google Street View in a dashboard in Tableau Online. I am new to coding and am curious if this conversation, particularly what you mentioned about Tableau, has to do with this error and if it's resolvable:

TYIA!

Hi @kendraspock , that error is a direct result of this. It's a little confusing since it doesn't actually mean Chrome refused to compile the WebAssembly module, it's reporting that if CSP were enabled, it would refuse to compile the module. It's benign.

I implemented successfully a compression protocol called Brotli here:
http://udpx.fasani.de
(It's an old fashioned Chrome app)
Even if wasm-eval seems to work I see that on many Web Assembly existing libraries they use eval() so that is a big restriction to use them for me right now. The funny thing is that I had to upload the binary WASM on a server just to give it back with the right CSP:

header("Content-Type: application/wasm");
header("Access-Control-Allow-Origin: *");

otherwise it won't work, but I though apps restrict scripts from remote URLs.

Has there been any update on this? Is the only way to use WebAssembly on websites on Chrome still to add 'unsafe-eval' to the CSP?

There has not been much progress on this in recent years.
There is an implementation of wasm-eval for chrome but it is restricted to ChromeOS at the moment.
All that being said, it is clear that the priority of this is rising and we are beginning to pick up the dusty threads :)

Argghhh I really want this for Ruffle as a user.

Just encountered the same issues with firefox, edge and chrome whilst trying to use wasm generated by blazor. Its a real stumbling block in moving from local development to production. Im quite surprised that there has'nt been more progression on this front given the push behind languages to adopt WASM compilation. Also im not sure about the adoption rate of browser updates across multiple platforms and regions etc however I am concerned because I assume that when this feature does eventually release there will be an issue where any application you're trying to rollout safely will for a long period of time only be accessible by a minority of browser users.

Just encountered the same issues with firefox

Surprised you encountered this in firefox, as far as I know firefox doesn't gate wasm compilation.

Now there is technically a way to use WASM on Chrome without unsafe-eval, as long as you can load a worker with unsafe-eval. This bypass doesn't work in Safari. Depending on your security needs, you might want to do something like per agent CSP policy

https://github.com/hackcasual/ChromeWASMCSP

Just encountered the same issues with firefox

Surprised you encountered this in firefox, as far as I know firefox doesn't gate wasm compilation.

It doesent block by default, the issue is if you deploy your application on a server with any kind of csp it seems to occur, though I suppose it's the same as enabling with a local document.

It's also unavoidable since it seems the method of using a js hash as you normally would with javascript in the csp causes it to still get blocked... And these alternative tags being discussed in the this thread when used in the csp also don't allow the execution either... In short csp equals no execution atleast in my tests (which aren't exhaustive as I mentioned).

But generally anywhere I would like to use wasm in production usually requires csps to be defined since security and reputation often are more valuable than performance gains.