Should WebAssembly be at the same "privilege level" as JS?

[littledan]

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.)

[guybedford]

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]

this sounds like something that would be represented in an esm resolver implementation, not this proposal.

[littledan]

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]

I agree that JS and wasm should run at the same privilege level. To isolate wasm, I think there should be two options:

• some solution orthogonal to wasm that works just as well for JS
• use instantiate (either via the JS API or via Module Linking)

[ghost]

Why should they be at different privilege levels?
If a web page author wants to write most of their code in WebAssembly, then they should be allowed to.
If they want the entry point of their code to be Wasm, instead of JS, why shouldn't they be allowed to?

It makes as much sense to lower one as it does the other, just because JavaScript is older, doesn't mean that it should somehow be more privileged.

When Wasm was first released, it seemed that it was intended to be somehow lesser to JS, that it is meant to augment and support JS.
Thankfully Wasm can call JS functions and is allowed to define a start function.

Now, with all of these proposals around Wasm, I feel that all of this can finally be equalized and that Wasm can be at the same privilege level as HTML, CSS, or JavaScript.

In truth, I would support Wasm being given direct access to JavaScript's global object, which would make this proposal redundant.

At the end of the day, it is the web developer that writes the code, so they should be level with each other.

[annevk]

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]

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.js in importObject.

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]

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...