Re: And so the cycle turns ...
One big problem with Java Applets is that Java started from more Desktop-y APIs and then locked things down.
WebAssembly is descended from Mozilla's asm.js and Google's Native Client and follows the JavaScript approach of aiming to approach "make evil commands unrepresentable" at the API level, and it does two things to avoid the applet outcome:
1. Like JavaScript (and thus, like asm.js), all its APIs are based on permission tokens passed in by the sandbox host. (eg. The WASI API for writing command-line applications doesn't let you ask to open "/etc/passwd" because WASI only provides a system call to open paths that are children of an FD the sandbox host passed in (basically, a secured wrapper around openat(2)), so, like with JavaScript in the browser, even the non-browser uses of WebAssembly need something that allows you to achieve arbitrary code execution in the sandbox host to break out.)
2. Like the Native Client loader's machine code checker, the WebAssembly loader restricts what machine instructions can be generated, requiring a vulnerability to be found in the loader to craft fully arbitrary input to the sandbox host APIs.
If you want to poke at WASI, the Wasmer runtime includes an NPM-like package system named WAPM and an npx analogue called wax and the default behaviour when running a command is to balance convenience and security by granting access to $PWD and nothing else and to use SSH-like "pin the first signature we see" behaviour if a package is signed.
Biting the hand that feeds IT
