4 ms·

The author mentions WebAssembly, yet writes at the end : " and a security model that allows us to forget that we run thousands and thousands of untrusted scrip

The author mentions WebAssembly, yet writes at the end : " and a security model that allows us to forget that we run thousands and thousands of untrusted scripts every day." WebAssembly is designed to run in a sandbox. I suppose that does not by itself make it completely safe, but it can not be much worse than the current situation, can it?

chii 9y ago
but isn't wasm something that is supposed to be compiled into native binary? Which means if there's a way to trick the compiler to compile something that looks innocuous, but when run (or somehow exploited) that it does something it's not supposed to? In chrome, the process sandboxing is supposed to protect you - it doesn't matter if it's wasm or not. Does other impl. of wasm does similar security-wise?
- grondilu 9y ago
  > but isn't wasm something that is supposed to be compiled into native binary? No, it compiles into a binary code of its own. That gives it near-native speed, but it's no "hardware-binary" code.
  - chii 9y ago
    ahh, i thought that the binary format is effectively something you (the runtime) translated into actual assembly (to be then executed).
atonse 9y ago
I think WebAssembly has a huge expectations problem: What many people think it is: I can compile my JS frameworks as assembly and ship binaries to the browser, that'll run near-native and be more compact. What WebAssembly actually is: a way to compile libraries from other languages in a manner that you can run them in a JS runtime, but with no access to the DOM, etc. (Think of things like shipping a JS based OCR library or a JS based audio-engine that runs at near-native speeds)
- floatboth 9y ago
  Yeah. I don't understand why people want this, or why people think it will bring huge performance gains… but someday in the future wasm will get direct DOM access. (And right now it's possible by exposing JS functions to wasm.)
- grondilu 9y ago
  > but with no access to the DOM There will be access to the DOM, but even without it, WebAssembly is still useful. You compile libraries that are performance sensitive, you use them from you JS code, and voilà, you have the best of both words : the flexibility and DOM access with JS, and the speed of compiled code with wasm.
  - atonse 9y ago
    Good point – I didn't it wasn't useful, just that there are a lot of people who think that you will be compiling React.js or jQuery as-is to WebAssembly, and just shipping them that way. That's just not how it'll work.
- tannhaeuser 9y ago
  Thanks for putting the discussion back into the realm of reality. For as long as I'm in IT, there has always been the story of an upcoming holy grail of technology that'll change everything aka the silver bullet. Reading through this thread, that role seems currently occupied by WASM, with wild projections of all kind of perceived problems of frontend development and beyond onto WASM. The reality is I have yet to see a single app making use of WASM on the web. And even when, if, there eventually is a WASM app, it won't be able to do anything that other (native) development environments haven't been able to do for ages. I'm not sure the world needs a new bytecode format, when only the ARM and x86_64 ISAs are still around. OTOH, what's new with WASM is that the browser and the internet acts as a gatekeeper for starting apps on your device, which I'm not sure will be met with enthusiasm by users. Furthermore, since WASM lacks APIs for even the most basic things, it would take ages to establish a platform, with all the fragmentation this entails.
  - 9y ago

chii 9y ago

but isn't wasm something that is supposed to be compiled into native binary? Which means if there's a way to trick the compiler to compile something that looks innocuous, but when run (or somehow exploited) that it does something it's not supposed to? In chrome, the process sandboxing is supposed to protect you - it doesn't matter if it's wasm or not. Does other impl. of wasm does similar security-wise?

grondilu 9y ago
> but isn't wasm something that is supposed to be compiled into native binary? No, it compiles into a binary code of its own. That gives it near-native speed, but it's no "hardware-binary" code.
- chii 9y ago
  ahh, i thought that the binary format is effectively something you (the runtime) translated into actual assembly (to be then executed).

atonse 9y ago

I think WebAssembly has a huge expectations problem: What many people think it is: I can compile my JS frameworks as assembly and ship binaries to the browser, that'll run near-native and be more compact. What WebAssembly actually is: a way to compile libraries from other languages in a manner that you can run them in a JS runtime, but with no access to the DOM, etc. (Think of things like shipping a JS based OCR library or a JS based audio-engine that runs at near-native speeds)

floatboth 9y ago
Yeah. I don't understand why people want this, or why people think it will bring huge performance gains… but someday in the future wasm will get direct DOM access. (And right now it's possible by exposing JS functions to wasm.)
grondilu 9y ago
> but with no access to the DOM There will be access to the DOM, but even without it, WebAssembly is still useful. You compile libraries that are performance sensitive, you use them from you JS code, and voilà, you have the best of both words : the flexibility and DOM access with JS, and the speed of compiled code with wasm.
- atonse 9y ago
  Good point – I didn't it wasn't useful, just that there are a lot of people who think that you will be compiling React.js or jQuery as-is to WebAssembly, and just shipping them that way. That's just not how it'll work.
tannhaeuser 9y ago
Thanks for putting the discussion back into the realm of reality. For as long as I'm in IT, there has always been the story of an upcoming holy grail of technology that'll change everything aka the silver bullet. Reading through this thread, that role seems currently occupied by WASM, with wild projections of all kind of perceived problems of frontend development and beyond onto WASM. The reality is I have yet to see a single app making use of WASM on the web. And even when, if, there eventually is a WASM app, it won't be able to do anything that other (native) development environments haven't been able to do for ages. I'm not sure the world needs a new bytecode format, when only the ARM and x86_64 ISAs are still around. OTOH, what's new with WASM is that the browser and the internet acts as a gatekeeper for starting apps on your device, which I'm not sure will be met with enthusiasm by users. Furthermore, since WASM lacks APIs for even the most basic things, it would take ages to establish a platform, with all the fragmentation this entails.
- 9y ago