5 ms·

This is pretty great! I remember building stuff with Flash back when it was still owned by Macromedia. There is a solid level of nostalgia for me there. I know

This is pretty great! I remember building stuff with Flash back when it was still owned by Macromedia. There is a solid level of nostalgia for me there. I know one of the major concerns became security with enabling the Flash player. I assume with WebAssembly as the compile target we don’t really have to worry about it as much? Does anyone know if we are going to start seeing things like memory leaks and buffer overflows with web assembly or is that not a thing? I know Rust does a lot to resolve memory issues but I’m wondering about the other languages that compile to web assembly. Anyways, nice work!

thristian 7y ago
One of the big problems with things like Flash and Java on the web was that they were separate codebases from the browser, but (often) ran inside the browser's memory space, which was kind of a worst-of-both-worlds situation: multiple VMs each with their own individual vulnerabilities, but compromising any one would give you access to all of them. WebAssembly is different because it's built around the high-performance JavaScript VMs that have been developed over the past decade or so. When a browser-maker fixes a security hole in their VM, it's fixed for JavaScript and WebAssembly at the same time, because they're built on the same foundation. So no, you don't have to worry about security as much with WebAssembly - not because of any magical security properties WebAssembly has, but because even though the WebAssembly API is new, the security environment has seen decades of hardening.
gridlockd 7y ago
WASM can't magically make memory-unsafe languages memory-safe. You can still have memory leaks and buffer overflows, but (assuming a correct WASM implementation) a buffer overflow can not result in memory access outside the WASM instance's memory space - unless you provide it with the facilities to do so.

thristian 7y ago

One of the big problems with things like Flash and Java on the web was that they were separate codebases from the browser, but (often) ran inside the browser's memory space, which was kind of a worst-of-both-worlds situation: multiple VMs each with their own individual vulnerabilities, but compromising any one would give you access to all of them. WebAssembly is different because it's built around the high-performance JavaScript VMs that have been developed over the past decade or so. When a browser-maker fixes a security hole in their VM, it's fixed for JavaScript and WebAssembly at the same time, because they're built on the same foundation. So no, you don't have to worry about security as much with WebAssembly - not because of any magical security properties WebAssembly has, but because even though the WebAssembly API is new, the security environment has seen decades of hardening.

gridlockd 7y ago

WASM can't magically make memory-unsafe languages memory-safe. You can still have memory leaks and buffer overflows, but (assuming a correct WASM implementation) a buffer overflow can not result in memory access outside the WASM instance's memory space - unless you provide it with the facilities to do so.