If you are at all concerned about confidentiality (as opposed to just integrity) properties, you need to defend against speculative execution timing attacks ("S

If you are at all concerned about confidentiality (as opposed to just integrity) properties, you need to defend against speculative execution timing attacks ("Spectre") and other uncooperative timing channels. Language based security like WASM can prevent untrusted code from receiving timing channels, but only by executing it absolutely deterministically and denying it anything that can be used as a clock, which definitely includes shared memory multithreading. So you would not be able to run anything originally multithreaded, except perhaps by heroic measures like a continuation passing lowering of fibers. If the code has any way to measure the passage of time, there is presently no known way to prevent it from using Spectre to read the whole memory of the process it is in. On the other hand process sandboxing can rely on defenses provided by the operating system and hardware. These are not IMO as absolute as deterministic execution, but they are better than nothing if it's not practical to run the untrusted code deterministically. Thus you see for example Chrome shifting its security model in the direction of assuming that anything mapped in the same OS process as untrusted JS or WASM has no confidentiality. I personally think it would be better, given the historically very limited access of JS to synchronous timing channels, to go for perfect determinism in that context. But definitely there are use cases where that isn't practical, so there is a place for process sandboxing. It also makes for a second line of defense - you can run your wasm vm inside your process sandbox, and an integrity failure of either one is not fatal!