Should WebAssembly modules be explicitly marked?

[littledan]

Various opinions are given in WICG/webcomponents#839. On one hand, Wasm is somehow equivalently powerful to JS, suggesting that the security needs are less stark. On the other hand, they have different parsers, so ambiguity may still be damaging. I don't think we need a final resolution within this proposal on this question, but this blocks WebAssembly/ESM integration. Cc @rniwa @annevk

[annevk]

@tschneidereit should confirm, but I think there is a strong argument for an explicit identifier as Wasm is strictly less privileged than JavaScript and whoever imports it might want to enforce those less privileged execution semantics.

(The only exception might be "top-level Wasm" which would somehow be able to get access to builtins in a way that is not yet defined. (I.e., when no JavaScript is involved.)

[littledan]

I don't see it as that much less privileged, when anyone on the internet could make a module (with CORS headers and everything) that re-exports JS globals in a Wasm-friendly way.

[annevk]

Ah yes, if the Wasm module could still import a JavaScript module there's an easy workaround. The marker would have to apply recursively, but that would get complicated quickly (as Wasm should probably still be able to import JSON).

[littledan]

It's a major goal of Wasm/ESM integration for Wasm to be able to import JS, too.

[annevk]

Understood, it would require some kind of hierarchy of privilege as noted in #7.

[bmeck]

This brings to mind, is this use about allowing opt-in security about executing code or about preventing side effects? It seems a that exposing evaluation able modules in non-side effect manners has some importance if we are looking at treating Web Assembly as special given such. To that mind, would importing a JS module that only exported function declarations and did not have side effects on load be placed in a similar special category?

[littledan]

I am not sure how to define that, but we should be able to add more categories over time once we have the infrastructure.

[devsnek]

could also apply the same rules to wasm imports and require them to have a custom section with type:whatever. if you didn't want the wasm to load anything else, you probably shouldn't be importing it in the first place.

[xtuc]

I like the custom section idea, a mapping between a module and attributes. I'm not sure how languages that compile to wasm will adopt it (if at all), but the mapping could be generated by a tool down the chain.

[littledan]

@xtuc Great. One decent-sized piece of technical work will be to design the binary format of such a custom section. Are you interested in this task?

[littledan]

(Note, maybe we should open a separate issue for the Wasm custom section, as it's a rather separate task from the decision about how we should mark things when importing WebAssembly.)

[xtuc]

@littledan, I'm happy to do it. This work could be on the WebAssembly CG side since it's really seperate.

[littledan]

@xtuc Agreed that this should be a WebAssembly CG proposal, but we could draft something early here and then split it out into a separate repo.

[littledan]

Marking this as "follow-on proposal" as it's a decision for the WebAssembly/ESM integration proposal.

[xtuc]

While this sounds like its own follow-up proposal. I'm concerned by what should be the module type when importing a Wasm module, which is a concret example of #16.