dirs VS wasmer

We've integrated wasmer ~1 year ago in our stack (video analytics and editing platform) to enable 3rd party plugins, but I'm not sure that I'd choose it again. The integration ended up too complicated and the thing I disliked most was that we had to reimplement/port a lot of the functionality we already had so that it worked with the wasm apis. I don't have insight on the wasm execution performance because we never really benchmarked it (it wasn't important for our use case since the plugins code is executed only once on app start or when manually triggered from the dashboard).

I'm not entirely convinced Wasmer will ever be able to shake its constant controversies.

I'm by no means a fan of the Bytecode Alliance, and would much prefer a startup tackle the problems that Wasmer is tackling, but between the trademarks [1], the lackluster response to the trademarks (How did you not know your lawyers were trying to trademark “WebAssembly”? Seriously?) [2], the working conditions [3], the drama surrounding the BCA [4][5], and everything else, I don't think Wasmer is the right choice either, at least not under current leadership.

[1] https://uspto.report/company/Wasmer-Inc

[2] https://wasmer.io/posts/wasmer-and-trademarks

[3] https://mnt.io/2021/10/04/i-leave-wasmer/

[4] https://github.com/wasmerio/wasmer/issues/956

[5] https://github.com/WebAssembly/WASI/issues/3

My advice is to use Wasmer's or Wasmtime's Rust bindings to embed a WebAssembly runtime.

Why use this over Wasmer?

Use a WebAssembly runtime like wasmtime or wasmer.

Java had an extremely advanced and strict sandbox for many years.

It offered of course also the possibility to blacklist everything by default.

The problem with such a granular sandbox is that it's too complex for most use cases.

When you need to whitelist any and every call to the outside world this becomes very tedious.

That's why Java now removes the sandbox…

https://inside.java/2021/04/23/security-and-sandboxing-post-...

Let's see how this works out for WASM.

I guess: Without resorting to using some language(s) with build-in support for capability security a whitelist based sandbox approach won't ever work without issues.

First of all you can forget about C/C++. Everything in this languages assumes free access to the system.

Rust does not have any support for capabilities either (yet, and for the years to come at least).

The best current WASM sandbox implementation, which is in Wasmer not WasmTime, is not more than a FS block. (And the memory safety guaranties you get in any VM language, of course).

https://docs.wasmtime.dev/security.html

I don't find any such feature mentioned in the Wasmer docs. It seems completely without any sandbox! (To stress it once more: All VM languages are memory safe. That's not sandboxing. All the "sandboxed by default" claims are misleading, at least).

https://github.com/wasmerio/wasmer/issues/221

That even people here on HN believe in the currently unfulfilled WASM security promises shows only how good the WASM marketing is. This should make you even more skeptical. One should never over promise on security! Java had to learn this the hard way over many years (as their sandbox had have holes in the past, and was also almost impossible to correctly configure).

This test might be useful (although it might be a bit hard to read because of the usage of macros) [1]. We will create a simple example of multivalue to showcase how it can be used

[1]: https://github.com/wasmerio/wasmer/blob/master/tests/compile...

That's the main reason we should start using WebAssembly for distributing and using packages.

Shamless plug: Wasmer [1] and WAPM [2] could help a lot on this quest!

[1]: https://wasmer.io/

[2]: https://wapm.io/