Repository navigation
Should WebAssembly be at the same "privilege level" as JS? #41
Description
This proposal lets WebAssembly import JS modules just as much as it lets JS import WebAssembly modules. The idea is that they're all part of the same big module graph. Logically, they can be thought of at the same "privilege level"--in HTML, this level would be based on the origin of the document that the module graph was loaded from.
Having WebAssembly and JS modules at the same privilege level contradicts the idea, which the Wasm/JS API supports, of WebAssembly only having access to what's passed into it explicitly. Instead, Wasm modules within ESM can make a request for any JS module--even on a different origin--and that JS module could package up any Web API in a form that can be accessed by Wasm. So, the thinking is a bit different.
Should we add Wasm/JS integration in a way which equalizes their privilege levels like this? Or should we consider certain restrictions, such as allowing JS to import Wasm, but not the reverse?
(Note, if we did have a "lower privilege" way of running code, there would be a massive demand to have this for JS modules as well. But it's unclear to me how this design should look. We're not talking about hard security boundaries here, since it's all within the same process, but more like softer isolation, what is given direct access to what, as with the Realm API.)
Activity
guybedford commentedon Nov 11, 2020
Interesting questions. When you mention JS modules as well in terms of privilege management, this may also relate to the isolated scopes proposal for restricting import capabilities.
devsnek commentedon Nov 11, 2020
this sounds like something that would be represented in an esm resolver implementation, not this proposal.
littledan commentedon Nov 11, 2020
Yeah, I agree that I'd like to separate these more complex questions from this proposal (so I do somewhat agree with @devsnek 's 😕 reaction), but I find that many, many people have the intuition that Wasm runs at a lower privilege level, so I'm not sure what order we should do these things in.
lukewagner commentedon Nov 11, 2020
I agree that JS and wasm should run at the same privilege level. To isolate wasm, I think there should be two options:
instantiate(either via the JS API or via Module Linking)annevk commentedon Nov 30, 2020
I don't think it's about JS vs Wasm and "privilige" might be the wrong word to use here; it's about Wasm having much better encapsulation than JS and letting Wasm import JS destroying that.
(And yes, I think there should be some kind of top-level Wasm that has access to the global.)
Pyrolistical commentedon Jun 6, 2021
We must retain backwards compatibility for security of all existing wasm by ensuring
WebAssembly.instantiate(bufferSource, importObject);fails given(import "./counter.js" "count" ...as there is no key of./counter.jsinimportObject.What we should do is introduce a new
WebAssembly.instantiateWithEsm(bufferSource)API for this proposal if we really want to have API parity in JS land.fgmccabe commentedon Dec 6, 2021
Jumping in with both feet ... :)
It seems to me that regardless of usage, importing a module (whether it is JS or Wasm) should simply be subject to the same requirements and access that the top-level module (i.e., the one mentioned in the script element) has.
Put another way, there are two orthogonal aspects: whether a given collection of modules may be imported or not and the wiring up of those modules into a coherent executable program.
Please forgive me if this is old news...
guybedford commentedon Jul 11, 2025
This was effectively resolved to be true in the HTML PR based on the argument that any cyclic module record can import any other cyclic module record and therefore exists at a similar privilege level transitively.