I’ve been thinking about ways to run user-supplied untrusted code in the browser, with an eye towards things like interactive demo programs in Wikipedia articles and user interface & editor extensions. Just running JavaScript provided by the user is wildly unsafe — it can dig into your web page’s UI and submit server requests on your user’s behalf without permission, for instance — and sandboxing things into iframes can be a bit funky and hard to fully lock down.
Current web browsers have another language they can run, though, which is WebAssembly — and WebAssembly makes much stricter sandboxing guarantees:
- Sandboxed code has literally no way to access memory or objects not provided to it
- no DOM access
- no network access
- no eval()
- Imported objects can only be numbers (read-only) or functions (call-only)
- Only numbers can be passed as arguments or returned to/from foreign functions
- Maximum memory usage can be set at compile time
- Compiled modules can be cached offline in indexedDB and reloaded safely
This means there’s no way an arbitrary wasm binary can access your document.cookies or submit a form, unless you pass in a function that allows that.
This also means that unless you provide an API to the wasm code, it can’t actually do anything other than calculate numbers. It also means that whatever API you do provide becomes a security boundary — you must make sure that you don’t introduce a function that can be exploited contrary to the security guarantees you want to make!
There are also a couple things that wasm by itself doesn’t solve:
- The halting problem — like JS code, wasm code can loop forever if it wants and there’s no way for the caller to interrupt it.
But wait — you can run a wasm binary in a Web Worker thread. And you can terminate Web Worker threads from the main thread! Depending on your API, if asynchronous messaging around the calls is workable this might be a good way to avoid hanging the main thread in the face of a misbehaving plugin.
So what’s the downside? Well, a few things to consider:
- wasm APIs must be wrapped to idiomatically transfer strings or data buffers with your main JS.
- Getting the emscripten compiler to produce “bare wasm” from C/C++ without assuming some JS imports are available seems tricky.
- C and C++ may not be the friendliest languages for plugin writers on text/GUI-heavy systems!
- Note rustc also has wasm compilation support, but the same concern applies.
- Any other language runtimes/libraries you use have to be built into the wasm binary… unless you rig up some kind of cross-module linking and ship multiple modules which link together, which seems super hard right now.
Something to consider for later. :D