Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

WebAssembly running in the browser runs in an isolated environment whose only access to the outside world is by calling out to JavaScript functions exposed to it when it was initialized. So it doesn’t open up any new APIs.

It does get recompiled to bytecode that runs directly on the processor, so in theory there could be vulnerabilities that come up from that, but I think it’s a pretty well-understood surface area at this point.



I know it's not fundamentally that different from the running arbitrary code we have right now, but something about the idea of indiscriminately running binaries invisibly downloaded over the WWW rubs me the wrong way.

Edit: read the first half of my sentence again.


> something about the idea of indiscriminately running binaries invisibly downloaded over the WWW rubs me the wrong way

I think that's because the word "binary" has connotations that aren't strictly technically justified. There's no difference between running WASM and running JS (which is usually obfuscated anyway). Both are JITted into machine code, and it's important the JIT is implemented securely. (JIT compilers have been sources of exploits.) The only difference is complexity of the source language, where simpler languages are easier to secure. And WASM is orders of magnitude simpler than JS.


That’s what we’ve been doing since the dawn of JavaScript, in a VM with a much larger surface area. A simper VM should be quite a bit safer than the status-quo.


I believe wasm will allow for far greater opportunities for code obfustation.

You can already do things like http://www.jsfuck.com/ and even more complex ones, but they would likely have bad performace.

With wasm you could do malware-level obfuscation with less drawbacks.


I have some bad news for you…




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: