>
The problem lies with in the sandboxing model. Sandboxes work great in principle, except that more toys that get added, the harder it is for the sandbox to keep all of the sand in.That's not really a meaningful analogy: computer sandboxes don't overflow and burst, the way that physical sandboxes do. There's no way to over-stress them and cause them to fail under load. They can have holes, but those holes are equally accessible to everything inside the sandbox, whether it's a hundred gallons of water or a single stick pointing directly at the hole.
The WebAssembly and JavaScript sandboxes are the same. In fact one of the current practical problems with WebAssembly as a general-purpose JS replacement (for the "I hate JS, I want to write in $language" use case) is that every interaction with the browser has to go through JS. The DOM API is exposed to JS. So WebAssembly is very slow unless you're using it for heavy computation or something that doesn't need much DOM interaction (e.g., a video game where you create a canvas, get a reference to it, and then draw on it without bothering JS any further).
The WebUSB problem was an API that was exposed to the sandbox that shouldn't have been, and was exploitable with very little code. That is, the problem was not that too much was inside the sandbox; it's that people deliberately cut a hole in the sandbox and didn't quite think through the implications of it.
> In JavaScript at least, the browsers could change how the APIs respond to fix the issue. In the case of WebAssembly, I honestly do not know if they are able to shut down vulnerabilities as quickly.
They can shut them down in the same way. WebAssembly uses the JS APIs.
> Now it would seem that we would have to run virus scanners directly in our browser on every binary that wants to run.
Virus scanners are a fundamentally broken model of security; that's why we've moved to sandboxes.
Sandboxes don't care what the app does, or how it does it. They certainly don't attempt to identify malicious code, the way an antivirus does. They just limit the capabilities of the environment in which the app runs. It doesn't matter what language the app is; if it doesn't have a "delete my files" API available to it (either intentionally or unintentionally), it can't delete your files. The worst that can happen is it can spend a lot of CPU being sad about not being able to delete your files... and you can just implement a CPU consumption limit, too.
> I would prefer WebAssembly is treated in the same fashion as Flash until the standard has settled and it’s security is proven.
The fundamental problem with Flash is that Flash was a different sandbox; it was a browser plugin, a piece of code that embedded itself directly into the browser itself and ran with full privileges on your desktop, that was expected to implement its own sandboxing. That sandboxing was designed by one company with a specific set of market pressures in favor of "ship cool things" and not as much in favor of "keep people secure", precisely because it was code running inside the browser that wasn't from the browser vendor.
WebAssembly just reuses the existing JavaScript sandbox (both the model and the specific implementation), and the model of which APIs are accessible has been hardened over time via public review and standardized development.
If you haven't heard the phrase "browser plugin" in a while (in favor of "browser extension"), it's because people realized that plugins were a fundamentally bad way of doing things, and we should instead focus our efforts on exposing cool new features incrementally to JavaScript and putting anything else we're excited about in the same sandbox as JavaScript. Occasionally there are mistakes in the sandbox model, like WebUSB. I am also sure that there will be mistakes in individual sandbox implementation that are somewhat easier to exploit with WebAssembly (but would probably still be exploitable with pure JS, just a little harder). That's why I think a paranoid browser for security nerds or high-risk people should have a way to disable it (and probably also a sandbox that excessively prioritizes safety over performance and correctness...). But I don't think as a general-purpose feature it's any different from JS.