3 ms·

As long as they don't let WebAssembly have raw access to the host filesystem, they'll do well. "No access" is the best access choice for the default. As adopti

As long as they don't let WebAssembly have raw access to the host filesystem, they'll do well. "No access" is the best access choice for the default. As adoption ramps up, the pressure to make filesystem access "easier" will increase. I just hope they hold it off, as isolation is the key feature of the platform.

capableweb 4y ago
> As long as they don't let WebAssembly have raw access to the host filesystem, they'll do well. "No access" is the best access choice for the default. Not sure where this worry even comes from? Browsers have never let anything (not even JS) have raw access to the host FS, so not sure why Wasm would be different. Edit: Ah, I realize now you might be thinking about running Wasm outside of browsers, via some other runtime. If so, I'd understand the concern as most desktop technologies allow unfettered access to FS and more.
- mikewarot 4y ago
  Browsers have never intentionally let anything outside the filesystem, the site the page is loaded from, etc... there are always escapes. The design of the WASM vm seems to preclude escapes, unless people get sloppy and make ladders that can be climbed out of. That's where my concern comes from.
- bariumbitmap 4y ago
  > Browsers have never let anything (not even JS) have raw access to the host FS I'm not sure what you mean by "raw access", but the File System Access API certainly allows web applications to do a lot of things. > The File System Access API (formerly known as Native File System API and prior to that it was called Writeable Files API) enables developers to build powerful web apps that interact with files on the user's local device, like IDEs, photo and video editors, text editors, and more. https://web.dev/file-system-access/ https://web.dev/file-system-access/ > After a user grants a web app access, this API allows the app to read or save changes directly to files and folders on the user’s device. Beyond reading and writing files, this API provides the ability to open a directory and enumerate its contents. Additionally, web apps can use this API to store references to files and directories they’ve been given access to, allowing the web apps to later regain access to the same content without requiring the user to select the same file again. > Additionally this API also makes it possible for websites to get access to some directory without having to first prompt the user for access. https://wicg.github.io/file-system-access/ https://wicg.github.io/file-system-access/ It's not just a draft, it's been part of Chrome since version 78 in 2019. > After a user grants access, this API allows web apps to read or save changes directly to files and folders on the user's device. It does all this by invoking the platform's own open and save dialog boxes. https://blog.chromium.org/2019/09/chrome-78-beta-new-houdini-api-native.html https://blog.chromium.org/2019/09/chrome-78-beta-new-houdini... Discussion at the time: https://news.ycombinator.com/item?id=21032537 https://news.ycombinator.com/item?id=21032537
nindalf 4y ago
Some of the folks developing wasmtime plan to run it as a server environment where any users can submit code to be run. They are very incentivised in making sure the sandbox can’t be broken.
russtrotter 4y ago
Technologies like WASI are coming on right now to do exactly this kind of access in the context of a sandbox. From what I can tell, they're going through a lot of the same progression of JVM and .NET IL back in the 90's and early 2k's but for whatever reason seem to be more openly embraced in all the places where WASM is gaining a foothold. I'm just keeping my fingers crossed that this one sticks .. oh and, please make WASM run in a browser without JS :)

capableweb 4y ago

> As long as they don't let WebAssembly have raw access to the host filesystem, they'll do well. "No access" is the best access choice for the default. Not sure where this worry even comes from? Browsers have never let anything (not even JS) have raw access to the host FS, so not sure why Wasm would be different. Edit: Ah, I realize now you might be thinking about running Wasm outside of browsers, via some other runtime. If so, I'd understand the concern as most desktop technologies allow unfettered access to FS and more.

mikewarot 4y ago
Browsers have never intentionally let anything outside the filesystem, the site the page is loaded from, etc... there are always escapes. The design of the WASM vm seems to preclude escapes, unless people get sloppy and make ladders that can be climbed out of. That's where my concern comes from.
bariumbitmap 4y ago
> Browsers have never let anything (not even JS) have raw access to the host FS I'm not sure what you mean by "raw access", but the File System Access API certainly allows web applications to do a lot of things. > The File System Access API (formerly known as Native File System API and prior to that it was called Writeable Files API) enables developers to build powerful web apps that interact with files on the user's local device, like IDEs, photo and video editors, text editors, and more. https://web.dev/file-system-access/ https://web.dev/file-system-access/ > After a user grants a web app access, this API allows the app to read or save changes directly to files and folders on the user’s device. Beyond reading and writing files, this API provides the ability to open a directory and enumerate its contents. Additionally, web apps can use this API to store references to files and directories they’ve been given access to, allowing the web apps to later regain access to the same content without requiring the user to select the same file again. > Additionally this API also makes it possible for websites to get access to some directory without having to first prompt the user for access. https://wicg.github.io/file-system-access/ https://wicg.github.io/file-system-access/ It's not just a draft, it's been part of Chrome since version 78 in 2019. > After a user grants access, this API allows web apps to read or save changes directly to files and folders on the user's device. It does all this by invoking the platform's own open and save dialog boxes. https://blog.chromium.org/2019/09/chrome-78-beta-new-houdini-api-native.html https://blog.chromium.org/2019/09/chrome-78-beta-new-houdini... Discussion at the time: https://news.ycombinator.com/item?id=21032537 https://news.ycombinator.com/item?id=21032537

nindalf 4y ago

Some of the folks developing wasmtime plan to run it as a server environment where any users can submit code to be run. They are very incentivised in making sure the sandbox can’t be broken.

russtrotter 4y ago

Technologies like WASI are coming on right now to do exactly this kind of access in the context of a sandbox. From what I can tell, they're going through a lot of the same progression of JVM and .NET IL back in the 90's and early 2k's but for whatever reason seem to be more openly embraced in all the places where WASM is gaining a foothold. I'm just keeping my fingers crossed that this one sticks .. oh and, please make WASM run in a browser without JS :)