Hi,
Is it possible to use local files used from the browser from Rust's WebAssembly (WASM) as if they were handling native code?
My goal is to handle huge SQLite files in a non-in-memory format in the browser. Is it possible to use a library like Rusqlite from WebAssembly (WASM) to achieve this?
No. Browser WASM does not have access to anything.
Any interaction between WASM and the world has to go through JavaScript, and therefore everything in WASM is limited exactly the same way JavaScript is limited.
There are some experimental JS APIs for access to local files from the browser, but that's more for a "save as" functionality for browser-based document editors rather than a normal filesystem access. You could probably extend it to work as a virtual block device for sqlite, but I don't know if it's been done yet. I would not expect this to work out of the box with rusqlite.
There are some JS hacks that expose sqlite files via HTTP, and there are several sqlite-in-the-cloud services.
Thank you for your reply.
Any interaction between WASM and the world has to go through JavaScript, and therefore everything in WASM is limited exactly the same way JavaScript is limited.
My customer claims that such a limitation does not exist because WASM can execute native code. I would like to prove "it can't" (devil's proof, I know), but is there any WASM documentation that describes the above constraint? Please let me know if you know of any.
Some standalone wasm runtimes allow you to call into native code from a wasm module via the same mechanism that allows a wasm module to call back into JS (imported functions). But you obviously can't do that in a browser, that would completely defeat the point of wasm's sandboxing.
The last FAQ on this page might be the closest you'll get to proving that negative with an actual official source.
WASM doesn't execute native code. Code is compiled to WASM bytecode, which browsers then run in their VMs, typically the same one as they use for JS. There are other ways to run WASM, from interpreters to wasm-to-c transpilers, but browsers always run it fully sandboxed and entirely isolated from the world. If browser WASM had same access as unsandboxed native executables, your computer would already be full of viruses injected by WASM from malvertising ads.
Note that code running natively is still a separate thing from running with access to the file system. For example Google's NaCL, an early WASM alternative, used to run native x86 code, but was still sandboxed. Modern systems are able to run any native code in a sandbox without access to anything.