4 ms·

Also, you know, it's safe unlike both of those. And, you know, it's not deeply connected to representing a single language like both of those. And, I guess unli

Also, you know, it's safe unlike both of those. And, you know, it's not deeply connected to representing a single language like both of those. And, I guess unlike those it's built by different companies following a standard rather than one company just pushing whatever they feel like that day of the week. But you're spot on otherwise. It's like they repeated the good parts of history and avoided repeating the bad parts. Weird.

kaba0 4y ago
I don’t really get this - the jvm bytecode itself has zero access to anything outside of some memory given to it. It can’t even print to stdout in itself, it needs a method with a native implementation for everything. So there really is no “safer” here. Of course libraries can be written that expose more and more functionality, but I don’t see anything inherently unsafe in the JVM as opposed to WASM, which is the exact same way. If anything, the jvm can’t even crash itself, while wasm is free to do all the old memory errors, just this time constrained to its virtual memory space.
jart 4y ago
The only thing I've ever seen webassembly used for online, was a hobby project where someone used it to get clang to run in the browser, which is cool, but kind of gimmicky, since no one wants to use a web page that needs to download hundreds of megs of dependencies. With Flash you could see the value like the Newgrounds animations it made possible, which would not have been possible otherwise. What has webassembly done for us besides turn the open web into opaque binary? Why is there no opt-out? It's the lack of consent that really gets to me. How many times do we have to say no?
- frosted-flakes 4y ago
  You've probably used WebAssembly many times without knowing it. Figma uses it heavily, for example. Why do you want to say no?
  - jart 4y ago
    What difference does it make why people want to say no? The issue is we're not being given a choice. WebAssembly is very new, it's controversial, it reduces transparency, and it increases the risk of exposing bugs in your hardware to every news site you visit as well as their ad exchanges. There should be a config option that lets people who are concerned about these things disable it.
    - slimsag 4y ago
      Do these browser options, which I will note are currently disabled by default, not work for you? | Browser | Option | Enabled by default | |---------|-----------------------|--------------------| | Firefox | dom.webgpu.enabled | Not yet! | | Chrome | #enable-unsafe-webgpu | Not yet! | I imagine this has something to do with why browser vendors have taken so long to ship WebGPU (another complaint I hear from WebGPU skeptics frequently), but what do I know.
pjmlp 4y ago
Usenix Security '20-Everything Old Is New Again: Binary Security of WebAssembly" https://www.youtube.com/watch?v=glL__xjviro https://www.youtube.com/watch?v=glL__xjviro "The Security Risk of Lacking Compiler Protection in WebAssembly" https://arxiv.org/abs/2111.01421 https://arxiv.org/abs/2111.01421
- slimsag 4y ago
  I talk about how Flash and Java applets can compromise the host OS arbitrarily, and you respond with a paper about how WebAssembly cannot do that but may lead to the program itself running in unexpected, isolated, ways. FTP: > The standard has been designed with security in mind, as evidenced among others by the strict separation of application memory from the execution environment’s memory. Thanks to this separation, a compromised WebAssembly binary cannot compromise the browser that executes the binary.
  - pjmlp 4y ago
    Yes, because first, you can compile heartbleed to WebAssembly. Secondly, because WebAssembly is yet to become the next target of security researchers, those papers are the first steps. Third, it is only a bytecode format, it cannot assure anything about the host implementation. Naturally there are yet flaws to be discovered.

kaba0 4y ago

I don’t really get this - the jvm bytecode itself has zero access to anything outside of some memory given to it. It can’t even print to stdout in itself, it needs a method with a native implementation for everything. So there really is no “safer” here. Of course libraries can be written that expose more and more functionality, but I don’t see anything inherently unsafe in the JVM as opposed to WASM, which is the exact same way. If anything, the jvm can’t even crash itself, while wasm is free to do all the old memory errors, just this time constrained to its virtual memory space.

jart 4y ago

The only thing I've ever seen webassembly used for online, was a hobby project where someone used it to get clang to run in the browser, which is cool, but kind of gimmicky, since no one wants to use a web page that needs to download hundreds of megs of dependencies. With Flash you could see the value like the Newgrounds animations it made possible, which would not have been possible otherwise. What has webassembly done for us besides turn the open web into opaque binary? Why is there no opt-out? It's the lack of consent that really gets to me. How many times do we have to say no?

frosted-flakes 4y ago
You've probably used WebAssembly many times without knowing it. Figma uses it heavily, for example. Why do you want to say no?
- jart 4y ago
  What difference does it make why people want to say no? The issue is we're not being given a choice. WebAssembly is very new, it's controversial, it reduces transparency, and it increases the risk of exposing bugs in your hardware to every news site you visit as well as their ad exchanges. There should be a config option that lets people who are concerned about these things disable it.
  - slimsag 4y ago
    Do these browser options, which I will note are currently disabled by default, not work for you? | Browser | Option | Enabled by default | |---------|-----------------------|--------------------| | Firefox | dom.webgpu.enabled | Not yet! | | Chrome | #enable-unsafe-webgpu | Not yet! | I imagine this has something to do with why browser vendors have taken so long to ship WebGPU (another complaint I hear from WebGPU skeptics frequently), but what do I know.

pjmlp 4y ago

Usenix Security '20-Everything Old Is New Again: Binary Security of WebAssembly" https://www.youtube.com/watch?v=glL__xjviro https://www.youtube.com/watch?v=glL__xjviro "The Security Risk of Lacking Compiler Protection in WebAssembly" https://arxiv.org/abs/2111.01421 https://arxiv.org/abs/2111.01421

slimsag 4y ago
I talk about how Flash and Java applets can compromise the host OS arbitrarily, and you respond with a paper about how WebAssembly cannot do that but may lead to the program itself running in unexpected, isolated, ways. FTP: > The standard has been designed with security in mind, as evidenced among others by the strict separation of application memory from the execution environment’s memory. Thanks to this separation, a compromised WebAssembly binary cannot compromise the browser that executes the binary.
- pjmlp 4y ago
  Yes, because first, you can compile heartbleed to WebAssembly. Secondly, because WebAssembly is yet to become the next target of security researchers, those papers are the first steps. Third, it is only a bytecode format, it cannot assure anything about the host implementation. Naturally there are yet flaws to be discovered.