4 ms·

WASM also takes a whitelisting approach to security rather than a blacklisting like the JVM. Java applets had lots of security issues over the years, whereas WA

WASM also takes a whitelisting approach to security rather than a blacklisting like the JVM. Java applets had lots of security issues over the years, whereas WASM provides much better isolation. Overall JVM or CLR always seemed too heavyweight for many use cases.

kaba0 4y ago
I do somewhat agree with the security aspects, though it seems to be in-process security measures are not the panacea. > Overall JVM or CLR always seemed too heavyweight for many use cases. The most common implementation may be; there are plenty of tiny jvms, some target embedded devices even.
- oblio 4y ago
  Yeah, but then you run into the problem of, "are those tiny JVMs": 1. Well supported by a company and a community 2. Are they free? Especially 2, it sounds ridiculous but frankly even huge corps just use free stuff whenever they can.
- still_grokking 4y ago
  > […] jvms, some target embedded devices even. Java was invented as IoT technology in the first place. Long before this acronym even existed. It run on all the old 4-line monochrome text display dumb phones. Java runs on SmartCards.
  - kaba0 4y ago
    Yeah, I know, but those are not the most streamlined ways of using Java nowadays, that’s why I didn’t highlight these parts as much (also, smartcards only run java ME, which is a subset of SE)
    - elcritch 4y ago
      Also most of them are also only support programming in Java. This always limited running arbitrary C code, or other languages like C++, Go, Nim, Rust, etc.
      - still_grokking 4y ago
        The JVM is Turing complete. So you can run any language you please on it. The question is—as always—how efficient this is. But this goes also the other way around. Even you can in theory run arbitrary languages on a WASM runtime the question how efficient this is stands also! And in fact running anything else than "C languages" in WASM is at least as inefficient as running "C languages" on the JVM…
        kaba0 4y ago
        > And in fact running anything else than "C languages" in WASM is at least as inefficient as running "C languages" on the JVM… Hell, it is a really safe bet to say that running a C-like program on the JVM is much much faster than porting a whole runtime (which is very performance-oriented) on top of a runtime and make it run some code. Wasm simply can’t expose the optimizations runtimes routinely make use of (template interpreters for example))
    - still_grokking 4y ago
      Sure! I wanted only to point out that using the word "even" in the cited part is kind of "funny". Because this was actually the originally intended usage of Java. It was invented as safe replacement of C/C++ especially for embedded development. (But now, sure, it ended up on the really huge boxes in DCs).
still_grokking 4y ago
Java had an extremely advanced and strict sandbox for many years. It offered of course also the possibility to blacklist everything by default. The problem with such a granular sandbox is that it's too complex for most use cases. When you need to whitelist any and every call to the outside world this becomes very tedious. That's why Java now removes the sandbox… https://inside.java/2021/04/23/security-and-sandboxing-post-securitymanager/ https://inside.java/2021/04/23/security-and-sandboxing-post-... Let's see how this works out for WASM. I guess: Without resorting to using some language(s) with build-in support for capability security a whitelist based sandbox approach won't ever work without issues. First of all you can forget about C/C++. Everything in this languages assumes free access to the system. Rust does not have any support for capabilities either (yet, and for the years to come at least). The best current WASM sandbox implementation, which is in WasmTime not Wasmer, is not more than a FS block. (And the memory safety guaranties you get in any VM language, of course). https://docs.wasmtime.dev/security.html https://docs.wasmtime.dev/security.html I don't find any such feature mentioned in the Wasmer docs. It seems completely without any sandbox! (To stress it once more: All VM languages are memory safe. That's not sandboxing. All the "sandboxed by default" claims are misleading, at least). https://github.com/wasmerio/wasmer/issues/221 https://github.com/wasmerio/wasmer/issues/221 That even people here on HN believe in the currently unfulfilled WASM security promises shows only how good the WASM marketing is. This should make you even more skeptical. One should never over promise on security! Java had to learn this the hard way over many years (as their sandbox had have holes in the past, and was also almost impossible to correctly configure).
- syrusakbary 4y ago
  > I don't find any such feature mentioned in the Wasmer docs. It seems completely without any sandbox! That's not correct. Wasmer aims to be a fully sandboxed WebAssembly Runtime. Wasmer WASI implementation is also fully sandboxed.
  - still_grokking 4y ago
    > Wasmer WASI implementation is also fully sandboxed. Could you please link to some authoritative documentation for that? As I said I don't see this in any docs or GitHub sources. The point is: It's irrelevant what they "aim for". The only interesting thing at the moment is the status quo.

kaba0 4y ago

I do somewhat agree with the security aspects, though it seems to be in-process security measures are not the panacea. > Overall JVM or CLR always seemed too heavyweight for many use cases. The most common implementation may be; there are plenty of tiny jvms, some target embedded devices even.

oblio 4y ago
Yeah, but then you run into the problem of, "are those tiny JVMs": 1. Well supported by a company and a community 2. Are they free? Especially 2, it sounds ridiculous but frankly even huge corps just use free stuff whenever they can.
still_grokking 4y ago
> […] jvms, some target embedded devices even. Java was invented as IoT technology in the first place. Long before this acronym even existed. It run on all the old 4-line monochrome text display dumb phones. Java runs on SmartCards.
- kaba0 4y ago
  Yeah, I know, but those are not the most streamlined ways of using Java nowadays, that’s why I didn’t highlight these parts as much (also, smartcards only run java ME, which is a subset of SE)
  - elcritch 4y ago
    Also most of them are also only support programming in Java. This always limited running arbitrary C code, or other languages like C++, Go, Nim, Rust, etc.
    - still_grokking 4y ago
      The JVM is Turing complete. So you can run any language you please on it. The question is—as always—how efficient this is. But this goes also the other way around. Even you can in theory run arbitrary languages on a WASM runtime the question how efficient this is stands also! And in fact running anything else than "C languages" in WASM is at least as inefficient as running "C languages" on the JVM…
      - kaba0 4y ago
        > And in fact running anything else than "C languages" in WASM is at least as inefficient as running "C languages" on the JVM… Hell, it is a really safe bet to say that running a C-like program on the JVM is much much faster than porting a whole runtime (which is very performance-oriented) on top of a runtime and make it run some code. Wasm simply can’t expose the optimizations runtimes routinely make use of (template interpreters for example))
  - still_grokking 4y ago
    Sure! I wanted only to point out that using the word "even" in the cited part is kind of "funny". Because this was actually the originally intended usage of Java. It was invented as safe replacement of C/C++ especially for embedded development. (But now, sure, it ended up on the really huge boxes in DCs).

still_grokking 4y ago

Java had an extremely advanced and strict sandbox for many years. It offered of course also the possibility to blacklist everything by default. The problem with such a granular sandbox is that it's too complex for most use cases. When you need to whitelist any and every call to the outside world this becomes very tedious. That's why Java now removes the sandbox… https://inside.java/2021/04/23/security-and-sandboxing-post-securitymanager/ https://inside.java/2021/04/23/security-and-sandboxing-post-... Let's see how this works out for WASM. I guess: Without resorting to using some language(s) with build-in support for capability security a whitelist based sandbox approach won't ever work without issues. First of all you can forget about C/C++. Everything in this languages assumes free access to the system. Rust does not have any support for capabilities either (yet, and for the years to come at least). The best current WASM sandbox implementation, which is in WasmTime not Wasmer, is not more than a FS block. (And the memory safety guaranties you get in any VM language, of course). https://docs.wasmtime.dev/security.html https://docs.wasmtime.dev/security.html I don't find any such feature mentioned in the Wasmer docs. It seems completely without any sandbox! (To stress it once more: All VM languages are memory safe. That's not sandboxing. All the "sandboxed by default" claims are misleading, at least). https://github.com/wasmerio/wasmer/issues/221 https://github.com/wasmerio/wasmer/issues/221 That even people here on HN believe in the currently unfulfilled WASM security promises shows only how good the WASM marketing is. This should make you even more skeptical. One should never over promise on security! Java had to learn this the hard way over many years (as their sandbox had have holes in the past, and was also almost impossible to correctly configure).

syrusakbary 4y ago
> I don't find any such feature mentioned in the Wasmer docs. It seems completely without any sandbox! That's not correct. Wasmer aims to be a fully sandboxed WebAssembly Runtime. Wasmer WASI implementation is also fully sandboxed.
- still_grokking 4y ago
  > Wasmer WASI implementation is also fully sandboxed. Could you please link to some authoritative documentation for that? As I said I don't see this in any docs or GitHub sources. The point is: It's irrelevant what they "aim for". The only interesting thing at the moment is the status quo.