Hacker News Reader

Comment by simonw | Hacker News Reader

Squoosh is the thing that really made me "get" WASM - it helped me understand that WASM suddenly makes the best-in-breed libraries for pretty much everything available to me in the browser, provided they can be compiled to it.

And the WASM sandbox should be airtight, which means it's much safer to run C code in WASM than directly!

I'm mainly a Python developer, so an accompanying revelation was that projects like wasmer-python then give me the same opportunity in my default environment - call out to best-in-breed C/Rust/etc libraries without the risk and misery of needing to compile and package them as Python extensions. Instead, wait for the JavaScript WASM community to figure out how to use them and take advantage of their work from my Python projects as well.

View on HN

What is the difference between WASM (new/good) and Java applets (old/bad)?

They try to do completely different things, it would be more meaningful to compare wasm with asm.js (let's try to improve a dynamic JITted language as a compilation target with simple semantics) and Java with Rust (let's try to make a language you could write anything in).

Java/JVM is a strong compilation target but it is mainly a language and an ecosystem, wasm is building an impressive ecosystem but it is mainly a compilation target designed to be easily embeddable anywhere.

Essentially the only things they have in common is the "run everywhere" slogan.

To actually answer your question with my opinions:

- wasm has a stronger sandbox and will (likely) never have any runtime reflection capability

- wasm is primarily meant to be easily embedded/interpreted

- wasm is extremely small

- it offers no new functionality that isn't already present in javascript (this will eventually become false)

- wasm lives within the sandbox of the browser

- it is standardized together with javascript inside the web platform, not as a separate entity

I'm not asking to compare Java with WASM. I'm asking to compare Java applets with WASM. They try to do one and the same thing. And the response I usually get, that the difference is that the applet sandbox leaked but the WASM sandbox is strong, makes absolutely no sense. Why would solving that problem involve tossing out applets only to replace them with a clone of the idea? How does that improve the sandbox? If the sandbox is the problem, why not work on that? How do you know how strong the WASM sandbox is, really?

Java Applets were running 2 separate sandboxes (the browser and the JVM) while hoping neither had security problems natively or with the interconnect. WASM is just a new way to nail code to the existing browser engine and sandbox.

My remembered experience of Java applets was that they loaded slowly, they required Java to be installed on the client computer (so they didn’t work out of the box for most people) and obviously they only run JVM code. Java applets also lived in an element on the webpage - which isn’t true of wasm. (But maybe there was also a way to run Java applets “headless”). I used to close websites if the Java applet loader appeared because otherwise I would be waiting for ages, and most of the time it wouldn’t work anyway because Java would be out of date or broken, or at best just slow and ugly.

In comparison, wasm apps have their own VM that is embedded into the browser. So there’s nothing extra for users to install (like the jvm). It’s small and lightweight, has (almost) no runtime SDK and it works on phones. I suppose you could write a compiler from C & Rust to Java byte code, ignoring most of the JVM’s features. But that big landscape of exposed features through the JVM still needs to be shipped somehow, and it’s a sandboxing nightmare that wasm just doesn’t have to contend with. Also let’s not forget that Google got sued over their use of Java by Oracle. I don’t want the web of the future to depend on any IP owned by oracle - that sounds like a disaster waiting to happen.

> Why would solving that problem involve tossing out applets only to replace them with a clone of the idea?

Because neither Sun nor browser vendors had interest in doing the work needed to improve sandboxing in Java; browser vendors had no say on Java development and Sun care more about non-applet Java

> How does that improve the sandbox?

The same way rewriting a C program in a memory safe language will decrease null pointer exceptions. wasm is closer to brainfuck in terms of functionality than Java applet.

> If the sandbox is the problem, why not work on that?

historically because nobody wanted of could, technologically it is what happened

> How do you know how strong the WASM sandbox is, really?

This only time will tell, but there are many reasons to be optimistic: wasm offers no high level functionality for rich interaction with the host environtment, all comunications are via function calls with only statically sized numbers and a linear memory, features in wasm were filtered to allow static strict typecheching and performance penalities where accepted where necessary (all memory accesses are bound checked)

My point is that Java applet and wasm are very different. Java applet are like Flash, it is a whole SDK, a programming model, and a separate process that live in a browser plugin.

The main use case of a Java applet is to run a java/JVM application inside an iframe with the motst of the JVM functionality at its disposal (one such feature is runtime reflection so that JVM bytecode is almost impossible to sandbox).

Sandboxing the JVM is close in complexity as sandboxing C: it is going to be hard and ultimately the larger ecosystem will not care about the compromises needed for it to work.

On the other hand wasm mostly tries to just be faster to run. In 2013 Mozilla released asm.js as a subset of javascript that was easier to optimize (it is how it became possible to run demo of unreal engine in javascript). The novelty of this approach was that asm.js was just javascript.

wasm is a continuation of this approach, its sandbox is stronger than Java applet sandbox because wasm is incredibly smaller and it lives inside the same engine as javascript.

Google tried to other way, developing separate plugin languages reserved for browser extensions like NPAPI or PNaCl, I do not know a lot about them, but as far as I understand they mostly worked fine and did not have security issues.

The applet sandbox didn't merely leak; it was non-existent.

Java applets had built-in access to the complete filesystem, network, shared memory etc. A java applet could read cookies, credentials etc stored on disk and transmit them elsewhere - this was not "hacking", it was merely "write the code to do it".

By contrast, the WASM standard offers no access to anything - no IO of any kind. The only documented way to do IO is to have the hosting code (eg javascript) pass in a function pointer to perform IO on behalf of the WASM.

You could definitely go looking for a vulnerability in a particular WASM engine which let you escape the sandbox on that engine - and I have real concerns about JIT type-confusion vulnerabilities, and the GPU as an attack vector. However, "find a vulnerability to exploit" and "call an officially-documented method" are very different approaches to performing IO.

> Java applets had built-in access to the complete filesystem, network, shared memory etc.

This is definitely not true:

https://docs.oracle.com/javase/tutorial/deployment/applet/se...

It says you can only access the local filesystem from "privileged applets" that are explicitly allowed to run outside the sandbox.

Part of it is that the design of WASM is informed by twenty years of additional experience as an industry.

It turns out we want something that is much smaller and much lighter than applets, and is developed as an open collaborative standard from the start.

We also want it built into browsers (so users don't have to install anything else).

Finally, it turns out we don't need it to be able to render directly its own area of the screen - a very non-obvious improvement over applets.

> which means it's much safer to run C code in WASM than directly

Anything is safer than to run C code directly ;)

Reply on news.ycombinator.com