[simonw]

The browser has offered this kind of sandboxing for JavaScript for decades at this point.

The reason I'm so excited about WebAssembly for this is that it's not even new technology: it's been supported by widely deployed browsers since 2017.

[Veserv]

Browser sandbox escapes from untrusted JavaScript are discovered and exploited regularly. JavaScript is much more constrained than the full force of a low level language like WebAssembly, and they can not even get the JavaScript sandbox safe to run truly untrusted or malicious code. Why would something harder to do work when they can not even do the easier thing?

Unless you are just talking about something meant to handle accidentally, not intentionally malicious code. Then sure, it is probably be okay for that. But if you are actually worried about malicious code then, no, browsers (and commercial operating systems) do not provide that. And anybody suggesting they can do that is almost certainly lying unless they also claim to have developed a unhackable operating system/virtual machine as well.

[simonw]

I know that it's hard, but I'm not ready to agree that this isn't worth seeking answers to.

AWS run untrusted code on Lambda all the time.

Browsers seem to be handling this pretty well in the face of the most untrustworthy computing environment our species has yet developed. Zero days in browsers are big news, and don't happen very often.

[Veserv]

If you can sandbox arbitrary malicious code, then you can make a unhackable operating system/runtime. Such a feat is frequently viewed as literally impossible in many software circles and would constitute a extraordinary claim that demands impeccable, extraordinary evidence to support it such as, minimally, mathematical proofs of the entire code base. Nothing less should overcome the sheer ideological inertia behind the common-sense view that everything is easily hacked as has been continuously demonstrated on basically everybody all the time.

So, unless you want to claim Amazon has invented a unhackable operating system to run AWS, has the mathematical proofs of correctness to support such a extraordinary claim, and has just not bothered to tell anyone, claiming AWS can actually securely run untrusted code is pure unsupported bluster. In fact, I bet exactly zero people at Amazon would back up such a claim if pressed, and if even the people doing it think it is impossible then there is no way they are actually doing it. The same goes for browsers.

As to zero days in browsers being big news, they are really not. Zerodium only pays 500 K$ for a Chrome RCE+LPE [1]. That is pocket change. Ransomware attacks ask for millions of dollars per attack these days. They can literally afford to burn multiple Chrome RCEs per attack (if needed) and still come out profitable. The cost of sandbox escape needs to be somewhere around 20-100x higher for it to be viewed as "secure" against the common threats seen every day.

[1] https://zerodium.com/program.html

[laurencerowe]

> AWS run untrusted code on Lambda all the time.

AWS uses virtualization (Firecracker) to provide isolation for Lambda.

WebAssembly vs browser/javascript isolation is a little like virtualization vs operating system level isolation. WebAssembly and virtualization offer far smaller attack surfaces which mean they are far more likely to remain secure in the long term.

Browsers and operating systems are highly complex abstractions and they only remain secure (if you keep them patched) through the large ongoing investment in them.

[incrudible]

Webassembly is far more constrained in the browser than Javascript. Exploits are flaws in the implementation that can be fixed, but what is being asked for is an environment that has fewer privileges by design.