The underlying problem is what the threat model was - in Java/JVM a significant amount of effort was put into addressing "what if the byte code itself is malicious", with the core applet VM having quite a lot of power over the system - e.g. file I/O, GPU access, etc.
> WebAssembly is still not safe from internal memory corruption, due to lack of memory tagging and bounds checking.
Unsafe applications won't ever be magically safe when compiling them to WebAssembly. Neither would this be the case when compiling to Java bytecode - if this was possible at all.
IMHO WebAssembly is a compilation target and therefore not the right layer to solve this. This is the responsibility of the language or the specific application. If you want to solve this in WASM, I predict you couldn't just compile all different languages to WASM anymore without significant changes to the codebases. If this would be feasible at all..
Rewriting those huge C/C++ codebases is simply not an option, new applications can be written in safe languages and then compiled to WASM.
Java bytecode requires bound checking and null pointer validation, as per the JVM specification.
CLR proves the contrary, by having C++ support, with the difference between safe Assemblies (where typical memory corruption opcodes are not allowed, compilation via /CLR) and unsafe Assemblies, where WASM like opcodes are allowed.
To load an unsafe Assembly, the host has to explicitly allow it.
Similar examples on IBM and Unisys language environments, e.g. on ClearPath, the admin must allow the execution of binaries tainted with unsafe code.
In general the groups doing standardization for browser APIs and runtimes don't seem to care much about whether web applications are compromised, only whether the browser or host platform are compromised. It's reasonable for the latter two to be priorities, but when we're talking about huge gmail-tier applications running unsafe C in a sandbox that have access to All Your Important Data, we're going to massively regret letting type safety and other features slide.
PHP may be memory safe but the shitload of poorly written C extensions enabled by default on all hosts that shipped with the distribution from 1995 to 2010 sure as hell weren't.
Yup, and work super aggressively to restrict it -- back when the JVM was supported, a large amount of the browser sandbox had to be extended to support the arbitrary behavior of the JVM, subsequently moving it out of process still required providing unrestricted access to OS components that you would rather they didn't.
At a very basic level it can be summed up with: the JVM approach to GLSL was to just throw it at the GPU, whereas the browsers worked on restricting WebGL to a super constrained subset (this was my fault, but is the correct thing to do :D )
By the time browsers were considering out-of-process plugins, the JVM was already thoroughly eclipsed by Flash. I think Flash's general brokenness (over half my browser crashes/hangs were caused by Flash) was the main motivation for out-of-process, not JVM's hugely broken sandbox.
Applets were eclipsed because of their monumentally expensive launch requirements - both time and memory.
The applets also made it hard to do a bunch of the simple games that were super popular - flash included a large amount of multimedia functions built in, and an editing environment that was geared towards interactive design.
The reason java took so long to move out of process was because the java<->browser bindings were unique to java, it did not use any of the normal plugin apis, and expected a lot of direct linkage to the host system.
The WebAssembly advocation force will tell you that everything is great and invented by WebAssembly, hand waving over the endless bytecode distribution formats that exist in computing since the 60's.