[nipplesurvey]

operating from the premise that most applet exploits functioned by elevating a sandboxed applet out of its sandbox (no idea if thats accurate), perhaps because java applets had an un-sandboxed mode built in, whereas wasm is always sandboxed and has no equivalent to applet's un-sandboxed mode.

[mike_hearn]

It's a bit tricky. I don't know if you can categorically say wasm is or will be more secure than applets. Both of them rely on a runtime that is more privileged than the code being executed, of course. Both of them can have runtime bugs that allow privilege escalation of various forms. There was a recent perma-root bug in ChromeOS and one of the exploits along the chain was based on exploiting a WebAssembly runtime bug.

If you look at Java's security track record in recent years, there's been just a couple of zero days in the past five years. That's probably a mix of genuinely better security and less attention due to being kicked out of web browsers. But if you go look at the security histories of other sandboxes like browsers or kernels, it starts to look pretty good. A new paper that just came out introduced a new Linux kernel fuzzer and discovered, I think, over 30 zero day exploits across several different Android phones. So ordinary UNIX style process isolation is pretty useless if you can reach device drivers from inside the processes. Even the quite aggressive and resource intensive browser sandboxes that browsers use routinely have escapes, often because they're always adding large new attack surfaces like WebAssembly, WebGL etc (all written in C++).

[nipplesurvey]

very interesting, did you read about the linux kernel fuzzer and the ChromeOS root here or elsewhere? regardless if you can provide a link either sound like very interesting topics.