I can't find the link right now but I seem to remember that Firefox already replaced some internal native subsystems with the same code compiled to WASM - or maybe even compiled to WASM and then translated back to C, which basically adds a runtime memory safety layer to unsafe C code at the cost of some performance (I think it was a couple of media codecs, but not sure).
Not sure why you think that WASM is less secure than JS though. Even if the WASM heap has internal corruption there's no way for this to do damage outside the WASM sandbox that wouldn't be possible in JS.
> I can't find the link right now but I seem to remember that Firefox already replaced some internal native subsystems with the same code compiled to WASM - or maybe even compiled to WASM and then translated back to C
Only parts of the browser are running in multiple small isolated WASM sandboxes, those WASM sandboxes are isolated from outside world about as well as if they would run in their own process.
Compartments of internally unsafe sandboxes are what we have now, with browsers employing native-code sandboxes and isolated renderer processes etc. It gets leaky.
Java applets didn't sandbox shit though, because you could call straight into your own native code via JNI (I know because I used exactly that approach to integrate a Win32 game client into browsers). The only thing that the applet launcher did was asking if it is ok to run the applet.
This is true, but adding a sandboxing to browsers has been a huge part in driving up the difficulty/cost of browser exploits, and driving down the frequency of their use.
And also we'll pay for a bypass of the wasm sandbox. (Actually, looking at our table, I'm going to try and get the bountyamount upped...)
