“but WebAssembly is designed to run safely on remote computers, so it can be securely sandboxed without losing performance.”
Assuming the hardware works correctly. This assumption is failing more often now. You pretty much have to know what the code is going to do up front to securely run it.
WebAssembly is the new SWF (Adobe Flash) ?!??!. A, potentially, binary format that we expect to run and do “totally not malicious” things on our computers delivered via our web browser.
I think it’s certainly the case that WASM has it’s use cases, and this maybe one of them. But, I’m so much more skeptical of it all than I am excited.
We’re already running untrusted JavaScript. A binary representation of JavaScript would be exactly equally safe. WASM is a binary representation of a language that’s simpler than JS and has the same or fewer capabilities. Whether JS is safe or not can be debated, but WASM isn’t a step down; it’s at worst a lateral move.
You could argue that it’s harder to inspect WASM (you need to translate it into its textual representation, and then read a language much lower level than JS), but really, reading through minified and obfuscated JS, or JS compiled from C, isn’t exactly easy either.
The APIs that come to talk to the environment outside of the waam runtime are going to be the deciding factor here
Safely crunching numbers types doesn’t get you very far.
“but WebAssembly is designed to run safely on remote computers, so it can be securely sandboxed without losing performance.”
Assuming the hardware works correctly. This assumption is failing more often now. You pretty much have to know what the code is going to do up front to securely run it.
WebAssembly is the new SWF (Adobe Flash) ?!??!. A, potentially, binary format that we expect to run and do “totally not malicious” things on our computers delivered via our web browser.
I think it’s certainly the case that WASM has it’s use cases, and this maybe one of them. But, I’m so much more skeptical of it all than I am excited.
We’re already running untrusted JavaScript. A binary representation of JavaScript would be exactly equally safe. WASM is a binary representation of a language that’s simpler than JS and has the same or fewer capabilities. Whether JS is safe or not can be debated, but WASM isn’t a step down; it’s at worst a lateral move.
You could argue that it’s harder to inspect WASM (you need to translate it into its textual representation, and then read a language much lower level than JS), but really, reading through minified and obfuscated JS, or JS compiled from C, isn’t exactly easy either.
I havent looked at it deeply yet. I have no opinion. Highly skeptical by default due to Worse is Better effect in web tech.
The APIs that come to talk to the environment outside of the waam runtime are going to be the deciding factor here Safely crunching numbers types doesn’t get you very far.
Periodic reminder: The Flash plugin was also supposed to be a set of safe APIs.
Sure. I’m not arguing for or against WASM. I’m just saying that current wasm doesn’t have any of those APIs at all.
That’s fair.
This was apparently inspired by Gary Barnhardt’s “The Birth and Death of Javascript”.