[maxmcd]

I feel like in this case those kinds of things are up to Zellij. If you run wasmer within the same process and share memory with the main Zellij process then yes wasmer/cranelift/wasmtime/wasm doesn't protect you from various speculative execution attacks. However, Zellij could run plugins in separate processes and apply things like seccomp to get further protections provided at the operating system level.

This is still not a complete security story and would not provide the same kind of protection as a VM, but I think the charitable take here is that this is a good sandboxing tool and a step in the right direction for something like a plugin system.

edit: I also disagree with the "fully sandboxed" wasmer line, but wasmer is a venture-backed for-profit org that will start selling something at some point and they might have a motivation to blur the lines a little. I appreciate cranelift's more honest disclaimer.

[chc4]

WASM and Wasmer are not intrinsically anymore secure, except for simplicity, than any other editor plugin system. Vimscript and Emacs-lisp basically have the same security characteristics as using WASM for plugins. It's not a step in any direction, except for whatever environment Zellij exposes to the plugins by default.

[maxmcd]

I'm not sure how this is true. I don't know anything about vimscript and emacs-lisp plugin systems, but at a cursory glance it looks like plugins might be able to do things like launch shell commands?

Zellij seems to be using WASI, a standard set of syscalls. Currently, wasi syscalls (or at least the version of wasi that is running in wasmer) can't really access the network, can't fork/exec, can provide a chroot view of the filesystems (without root access), can limit access to certain types of functionality. These kind of secure defaults seem like an improvement to me compared to most plugin systems I'm familiar with.

Maybe vimscript/emacs-lisp has these things.