It is not proven at all. Black hat hackers are yet to be bothered to attack it.
Those WASM related CVEs will start coming when they do.
For starters it lacks bounds checking on memory access inside the sandbox, which is an easy target if the module happened to be originally written in C, C style C++, or any other systems language without bounds checking enabled by default.
Not even its Harvard architecture based design can help there.
The JVM stumbled in library logical errors implementation and FOSS devs hate.
While WASM for whatever reason has become the new hip child, with many acting as if it hasn't never been done before.
Plenty of IoT devices with sandbox based VMs for download of hostile code have been designed throughout the years. WASM is just yet another one.
I think the biggest punishment for all that cheering will be the return of Flash, ActiveX, Java, ..., using Canvas/WebGL/WebGPU and now you cannot turn it off.
you seem concerned about security (which was a big factor against the flash VM), but i was more thinking about performance and integration with the environment. Java applets were slow, couldn’t run on most mobile browsers and were sticking out like a sore thumb on each page they ran into.
I was talking about the javascript VM (not specifically wasm), which has been the target of hackers for years and run fine on even modest mobile phone.
i understand running VM assembly code directly may change a few things relative to security, but other than that we pretty much have the guarantee that wherever javascript is able to run today, wasm will be, and the experience is going to be better (don’t see why wasm couldn’t call the DOM once browser decide it)
