Squoosh: Make images smaller using best-in-class codecs, right in the browser

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.

> 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.

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.

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.

The file sizes quoted should be for the resolution of image actually displayed. It would be fine to say a 960x540 image is X bytes with AVIF and Y bytes with JPEG and let viewers judge for themselves whether the two look equivalent. What that page actually does is quote the file sizes for 1920x1080 images, but shrink them to 960x540 before letting viewers compare the compression quality.

Are you saying that people don't ever zoom in on images on the web? Because my wife does this regularly to look at details in photos.

Ohh does that mean we can have the argument again?

> You could denote the difference with a sign, like “-30%” but that still confuses people

How? This doesn't seem to be a problem whenever a shop runs a sale.

You could write "shrunk by/to x%". Or, to stay with the app's theme, "Squooshed by 30%!"

> "0.7x compression" cannot, I think, be misunderstood

FWIW I'm not sure what your intended meaning is here. I interpret it to mean that the file got bigger.

Great tip, thanks for sharing!