Not sure if I'd trust the wasm runtime. If someone breaks out of that it's game over. QuickJS in a unikernel in something like Firecracker VM would be the most secure approach and still provide good performance and startup time.
Another thing is resource consumption where you likely want to limit cpu- and mem-usage.
I recommend Lambda as an easy way to create ephemeral Firecracker VMs and set overall limits on host + guest. For casual use, the memory and CPU limits available in the library should be enough.
I use it on both client and server. A easy way to get excellent security in the server is to run inside AWS Lambda or similar FaaS that uses strong VM isolation; ideally with a lambda instance per user.
Comments
Would you use this to run untrusted JS on the server?
From what I understand, this allows you to run untrusted js anywhere, as long as there’s a wasm runtime.
This repo in particular is for JavaScript host environments
Not sure if I'd trust the wasm runtime. If someone breaks out of that it's game over. QuickJS in a unikernel in something like Firecracker VM would be the most secure approach and still provide good performance and startup time.
Another thing is resource consumption where you likely want to limit cpu- and mem-usage.
I recommend Lambda as an easy way to create ephemeral Firecracker VMs and set overall limits on host + guest. For casual use, the memory and CPU limits available in the library should be enough.
I use it on both client and server. A easy way to get excellent security in the server is to run inside AWS Lambda or similar FaaS that uses strong VM isolation; ideally with a lambda instance per user.
You can just run QuickJS (without std lib) as a separate process running as an unprivileged user with seccomp rules.
WASM probably doesn't add much there.