4 ms·

Webassembly can access anything you give it access to, and only that. That’s great from a trust perspective because it means you can use a binary blob with con

Webassembly can access anything you give it access to, and only that. That’s great from a trust perspective because it means you can use a binary blob with confidence that it can’t do anything it isn't explicitly allowed to. There’s no reason to specify access to the DOM for webassembly since you can grant that access from JS. The hard bit is making it fast; ideally you could call between WASM and browser code with zero trampolines, but going via JS means you need two.

als0 6y ago
> There’s no reason to specify access to the DOM for webassembly since you can grant that access from JS. There are reasons. If I could write web apps in a different language without having to use any JS, I would. It would be wonderful to be able to pick whatever language you want, compile it, and then deploy it. Having a JS bridge just seems like a clunky workaround that you have to live with. > That’s great from a trust perspective because it means you can use a binary blob with confidence that it can’t do anything it isn't explicitly allowed to. JavaScript is already sandboxed and can access only what you allow it to. Why have a sandbox within a sandbox?
- danielheath 6y ago
  > Having a JS bridge just seems like a clunky workaround that you have to live with. It's 100 lines of code that you write once and never touch again. Not especially hard to live with VS having a fixed spec that can't evolve over time. > JavaScript is already sandboxed and can access only what you allow it to. Why have a sandbox within a sandbox? Javascript can access only what the user grants it access to. Within that set, WebAssembly can access only what the site author grants it access to. There are quite a few good reasons to want nesting sandboxes. Hell, that's my favorite thing about Lua (a language I would otherwise avoid).

als0 6y ago

> There’s no reason to specify access to the DOM for webassembly since you can grant that access from JS. There are reasons. If I could write web apps in a different language without having to use any JS, I would. It would be wonderful to be able to pick whatever language you want, compile it, and then deploy it. Having a JS bridge just seems like a clunky workaround that you have to live with. > That’s great from a trust perspective because it means you can use a binary blob with confidence that it can’t do anything it isn't explicitly allowed to. JavaScript is already sandboxed and can access only what you allow it to. Why have a sandbox within a sandbox?

danielheath 6y ago
> Having a JS bridge just seems like a clunky workaround that you have to live with. It's 100 lines of code that you write once and never touch again. Not especially hard to live with VS having a fixed spec that can't evolve over time. > JavaScript is already sandboxed and can access only what you allow it to. Why have a sandbox within a sandbox? Javascript can access only what the user grants it access to. Within that set, WebAssembly can access only what the site author grants it access to. There are quite a few good reasons to want nesting sandboxes. Hell, that's my favorite thing about Lua (a language I would otherwise avoid).