11 ms·

> ..., to the web And not only. From the paper: "WebAssembly is an abstraction over modern hardware, making it language-, hardware-, and platform-independent,

by yaantc 9y ago

> ..., to the web And not only. From the paper: "WebAssembly is an abstraction over modern hardware, making it language-, hardware-, and platform-independent, with use cases beyond just the Web". It could have some use in the embedded space, for securely embedding code. Java is sometimes used to sandbox code, if the WA compiler is slim enough it could be an alternative. A big difference is of course the libraries, which are not in the WA scope. But for some embedded use cases this is not a blocker: the API is there at the C level, one just need to expose it to the WA runtime (which could be automated, see SWIG and the like). A secure format, with some strong backers and high performance open source implementations has a lot of potential. I'm very curious about the footprint of the loader/compiler/runtime: it should be ok for most Linux embedded systems, but how low-end could it go as a secure ISA agnostic code distribution system? For your second point, JavaScript is also sandboxed. On principle, there is no reason that in time the API offered to JS today won't become available to the WA runtime in the future --- although I've no idea if there's any actual work along those lines, I don't follow web front-end tech too closely.

austincheney 9y ago
> For your second point, JavaScript is also sandboxed. There are all kinds of abstractions interact with the language outside the sandbox though: DOM, XMLHttpRequest, WebSocket, Cookies, location object, localStorage, IndexedDB, and on and on.... To my knowledge WASM does not have such a variety of APIs to expose access. The reason for this difference is that the security emphasis for WASM is instruction integrity while with JavaScript the emphasis is integrity of IO. WASM runs closer to the metal and so if any of the security CIA (confidentiality, integrity, availability) are broken everything that relies upon it, executes from it, or works with it could be exposed through memory. In this case it is the execution state that is important. JavaScript is not a bytecode format and so it can execute in a VM without the VM ever being exposed. All that matters for JavaScript is that it receives standard input and returns standard output.
- ChrisSD 9y ago
  Actually the eventual goal is to give WASM access to import "environment" apis, which in the browser means DOM, Cookies, etc. See the design documents: https://github.com/WebAssembly/design/blob/master/Portability.md#api https://github.com/WebAssembly/design/blob/master/Portabilit...
jfbastien 9y ago
You should be able to write a very basic WebAssembly compiler in much less than half a megabyte. The WebAssembly format itself can be assumed to already be pre-optimized, and is expressed in terms of i32/i64/f32/f64 with an infinite register set and stack machine, with a very well structured control flow. You really don't need a smart compiler to lower this to semi-efficient code. The runtime in a non-JavaScript embedder then has to expose a series of syscalls, but that's not very big either.

by yaantc 9y ago

austincheney 9y ago

> For your second point, JavaScript is also sandboxed. There are all kinds of abstractions interact with the language outside the sandbox though: DOM, XMLHttpRequest, WebSocket, Cookies, location object, localStorage, IndexedDB, and on and on.... To my knowledge WASM does not have such a variety of APIs to expose access. The reason for this difference is that the security emphasis for WASM is instruction integrity while with JavaScript the emphasis is integrity of IO. WASM runs closer to the metal and so if any of the security CIA (confidentiality, integrity, availability) are broken everything that relies upon it, executes from it, or works with it could be exposed through memory. In this case it is the execution state that is important. JavaScript is not a bytecode format and so it can execute in a VM without the VM ever being exposed. All that matters for JavaScript is that it receives standard input and returns standard output.

ChrisSD 9y ago
Actually the eventual goal is to give WASM access to import "environment" apis, which in the browser means DOM, Cookies, etc. See the design documents: https://github.com/WebAssembly/design/blob/master/Portability.md#api https://github.com/WebAssembly/design/blob/master/Portabilit...

jfbastien 9y ago

You should be able to write a very basic WebAssembly compiler in much less than half a megabyte. The WebAssembly format itself can be assumed to already be pre-optimized, and is expressed in terms of i32/i64/f32/f64 with an infinite register set and stack machine, with a very well structured control flow. You really don't need a smart compiler to lower this to semi-efficient code. The runtime in a non-JavaScript embedder then has to expose a series of syscalls, but that's not very big either.