It’s the difference between sandboxing and true isolation, between blacklisting and whitelisting. With something like CPython or the JVM, you’re attempting to

It’s the difference between sandboxing and true isolation, between blacklisting and whitelisting. With something like CPython or the JVM, you’re attempting to sandbox something that was designed to be able to run arbitrary code, and was never designed to be restrained in this way, and if you miss even one thing, it’s completely broken. https://web.mit.edu/jesstess/www/pytennessee_sandbox.pdf https://web.mit.edu/jesstess/www/pytennessee_sandbox.pdf is a good summary of what a problem this is, and why it’s basically impossible to secure that way: you’re plugging a huge number of leaks in a massive surface area, and you will not get it watertight—to say nothing of the fact that lots of software depends on those leaks existing (for perfectly benign reasons). And every C extension that you load increases the vulnerable surface area (e.g. https://www.hebergementwebs.com/news/escape-a-python-sandbox-with-a-memory-corruption-bug https://www.hebergementwebs.com/news/escape-a-python-sandbox... describes using a numpy bug to escape a CPython sandbox). You just can’t run a successful sandbox inside CPython or the JVM; instead, you must run the language inside a sandbox—and even that is often troublesome. WebAssembly, on the other hand, is isolated. There are no leaks, and the surface area is tiny, because it was designed that way. It can’t do anything directly save computation on what it’s given; it depends on the runtime to grant it access to any external resources. This completely guards against all direct attacks, leaving only side-channel attacks, which are a vastly less dangerous class in general, and easier to guard against once you know about them, because the runtime controls execution.