add CSP policy note

[guybedford]

Since the Wasm CSP proposal is Phase 3, it seems prudent to make a note now as to how the ESM Integration interacts with the CSP proposal. Depending on which progresses into the spec first, the correct rebasing of specification can then happen at that time, but at least this ensures there is no ambiguity in this area for now as implementations seek to progress.

[annevk]

I think you should explain more why script-src suffices here and perhaps also how this is different from importing JSON.

I think the idea is that JavaScript module scripts and Wasm module scripts would have equivalent power in terms of API access and therefore treating them as interchangeable is okay. From the JS side that's at least supported by JS having pretty much full Wasm access. I don't really know how Wasm module scripts are going to work, but last I checked they were not really limited in any capacity.

Given import {foo} from "./myModule.wasm"; perhaps the idea is they would not at all be a different type from JavaScript module scripts?

cc @noamr @nicolo-ribaudo

[nicolo-ribaudo]

Wasm modules are more limited than JS modules because they do not have direct access to the JS global object and to the DOM, however:

1. they can import other JS modules, and get access to any JS API through them (although that Wasm->JS import would still be controlled by the script-src policy, regardless of what the Wasm policy is)
2. differently from JSON/CSS modules, Wasm modules can have infinite loops and make a page crash

Due to (1) it would be possible to have a more relaxed policy for Wasm, but its fallback should definitely be script-src and thus I agree it makes sense as a starting point.

[noamr]

script-src makes sense to me here.

[annevk]

That makes me think they should be a separate type from JavaScript module scripts then.

1. Making the page crash is not unique to Wasm as JS can do that too. So not too worried about that.
2. Offering some kind of sandboxed compute however is novel and something you could wish to limit a module too. Because if you're careful about your script-src it could in fact guarantee that, but that would no longer be possible if someone could swap out the Wasm for JS. (And we could build on this in the future by offering wasm-src as a more specific script-src at some point.)

I think that would mean these things:

1. A fetch destination for Wasm module scripts.
2. A "wasm" import attribute type.

[guybedford]

@annevk this is a great point, I agree with you about the wasm-src requirement here if we are to treat Wasm as a sandbox. Putting some further thought to it though, from the start we will have equal capability indirectly through imports anyway, since by allowing Wasm to import JS we give it equal abilities. And those capabilities may extend over time, especially for any host imports in future, so that this capability gap will likely narrow to the point where the language distinction is not the important distinguisher. I've updated the note to specifically note that they are equal permissions. @lukewagner may well have more feedback on this.

[lukewagner]

Adding to what @guybedford said, it seems like, if we succeed with enabling tight WebAssembly+JS/Web-platform integration (enabled by ESM-integration and perhaps one day built-in modules and Web IDL reflected as built-in modules), thenimporting a wasm module won't be meaningfully different than importing a JS module. And if ECMAScript Module Phase Imports and follow-up proposals succeed, than, iiuc, import source'ing a JS module can be just as sandboxed as import source'ing a wasm module. And that symmetry seems good for developers.

[annevk]

from the start we will have equal capability indirectly through imports anyway, since by allowing Wasm to import JS we give it equal abilities

I don't think that follows from what was said above. If your script-src only allows for a Wasm module to be imported (perhaps even a specific one) and doesn't allow for anything else, that Wasm module won't have global access. Being able to enforce that seems good.

[lukewagner]

@annevk

that Wasm module won't have global access

Wasm may not have a built-in global object, but it's easy enough for wasm to get a hold of the global object (literally as an externref) by calling function imports resolved via normal ESM rules against the whole of the module-map. Thus, if you constrain an ESM import (via { type: 'wasm' }), you really won't have gained much in the way of invariants. If you want invariants, you want to use WebAssembly.instantiate() (and import source).

[annevk]

You'd have to constrain via type: 'wasm' and CSP script-src, yes. Given that Wasm has rather different properties I'm worried we'll regret not giving it its own import type.

[guybedford]

It is also worth noting WebAssembly may well be enabling builtins to be provided through the default ESM integration compilation in future for example via https://github.com/WebAssembly/js-string-builtins/blob/main/proposals/js-string-builtins/Overview.md#using-builtins, where the compilation under the ESM integration would in future enable features like this. String functions likely aren't a security concern, but this list may well grow in functionality in place of the intrinsic and global access JS has already.

[noamr]

Isn't the sandboxed compute environment for WASM similar to shadow realms in terms of capability? I'm not sure if qualifying this as a wasm vs script feature is the right approach, perhaps there should be a policy for sandboxed execution, whether it's wasm or js.

[annevk]

Maybe? From our perspective it's important that different module formats have different identifiers and cannot be interchanged (except perhaps if you explicitly opt into that).