Mozilla has announced a new standardization effort to provide a consistent way for WebAssembly applications to interact with any operating system they run on.
Dubbed WASI, or WebAssembly System Interface, the currently experimental project provides WebAssembly applications with a set of abstractions for performing tasks such as reading and writing files and network I/O. Each WebAssembly host implements WASI for the platform it runs on.
A key part of WASI, according to Mozilla, is that it is platform-independent. Languages like C provide a standard library to interface with the file system and memory, for example. Similarly, WASI can be thought of as a standard library for cross-platform abstractions like files or network sockets.
Another key element of WASI is that these behaviors are sandboxed. One example given by Mozilla is file access. A WASI-managed call to open a file would only work for the directories the application has explicit permission to read from or write to. Those permissions could also be limited per module.
Using WASI will require recompiling existing WebAssembly to work correctly, but WebAssembly is still early enough in its development that a change like this isn’t likely to be disruptive. Right now, two of the major toolchains for writing WebAssembly apps, Rust and C/C++, support WASI. Both leverage LLVM’s ability to generate WebAssembly code to achieve this.
To run WASI-enabled apps, you currently need more than stock WebAssembly support in the browser. One method is to use a browser-based polyfill, in much the same way that experimental features of JavaScript can be used. Another is by way of wasmtime, a standalone WebAssembly runtime that doesn’t use a browser. A third is yet another standalone runtime, Lucet, built by way of Mozilla’s Cranelift code generation system. Mozilla hopes that in time browsers will support WASI natively.
