Not sure what you were expecting, but no, Wasm doesn't magically make memory-unsafe languages internally uncorruptible, it limits all corruption to internal state. If you look at the PL research stretching back a couple decades on how to do that for C, you are looking at integer factor performance overheads in the general case. Wasm also doesn't make anything less safe than it was before (ok, ok, modulo the current lack of read-protected memory), and since we wisely chose to make the execution stack non-addressable, has CFI by default.

Wasm's sandboxing makes it impossible to escalate the privilege of a program or acquire capabilities that it didn't have before (i.e. were not explicit imported and granted). That's a strictly stronger primitive than a random userspace Unix process.

I was expecting that people don't oversell WebAssbemly as some kind of magic pixie dust of security, anyone that knows a bit about security spots those flaws.

You know what is also sandboxed? An OS process.

Ah, but an OS process has a wider syscalls surface, well lets than bring WASI or JavaScript bindings into the picture.

At least we are on the same page on the level of sandboxing provided. For the record, it was your comment that called it a "big mistake" to not have finer-grained memory protection. I explained why we did that. And now you're saying someone "oversold" it as magic pixie dust? I'm not sure which hype train you're referring to, TBH. It wasn't core members or the CG, as we understood very clearly which security properties we were gaining and which we were not gaining.