Exactly. AFAIK the idea is the same as 1990's COM or CORBA, but for WASM (e.g. being able to call between WASM "DLLs" written in different languages but without having to define a C API for each DLL), so pretty much irrelevant for statically linked WASM apps or anything that uses C APIs anyway to talk to each other.
> pretty much irrelevant for statically linked WASM apps
One benefit off the top of my head is the extra isolation between component instances within this statically linked app: you can be shielded from many of the ways libwhatever might ruin everything because its linear memory can be totally isolated from the root component (and vice versa) with surprisingly little overhead.
The Wasm Component model takes security seriously, much in the way that Core Wasm does. Even without everything else it has to offer, this is something our craft is desperately in need of.
If Core Wasm took security seriously, the memory access opcodes for arrays would be bound checked like on MSIL and TIMI, instead of "as long as it is inside of a linear memory segment we're good" approach.
Arguably, memory safety inside the WASM heap is the job of the compiler, it's often possible to omit runtime range- and null-checks with the control-flow knowledge the compiler has access to which would be tricky to transmit down to the bytecode level (and even then it would only benefit a handful of languages that have builtin concepts for "ranges" and "nullability".
If you need more fine-grained isolation, split your code into different WASM instances.
"Arguably, memory safety inside the UNIX process heap is the job of the compiler, ...."
See what I did there?
And then we are back at the root problem of goverments having to step in, and hardware vendors coming up with hardware memory tagging, because that isn't scaling.
> "Arguably, memory safety inside the UNIX process heap is the job of the compiler, ...."
In my mind there's nothing controversial about this statement at all.
If memory corruption inside the sandbox allows to manipulate anything outside the sandbox, then the sandbox is broken. It's as simple as that, and it doesn't matter whether it's the WASM heap or a process heap.
And if there is no guarantee that the sandbox is on a safe state, whose execution doesn't translate into nasty side effects, like return true instead of false on a credential check, due to internal memory corruption, then it is equally broken.
It becomes the same approach as attacking OS processes via their public OS IPC end points.
and CM copies everything everywhere between components - so this fictional need to build your program out of wasm components made of several languages which in turn also may link many components will just be a nightmare for performance and memory. WIT has to have a “borrow” concept to alleviate the pain.
