4 ms·

Last time I checked, all the abilities for directly manipulating JS reference types in WASM had yet to even be deployed outside of developer trials. So there’s

Last time I checked, all the abilities for directly manipulating JS reference types in WASM had yet to even be deployed outside of developer trials. So there’s a much simpler solution that (a) doesn’t depend on “just” statically analyzing the binary and (b) doesn’t use features that most browsers don’t support. Just expose precisely the Firebase or whatever functionality you wish to through normal WASM imports. No overhead of checking the file for safety at all (beyond the built-in WASM validation and translation of course). And binding the functions for e.g. WebGL directly with a lookup table for passed in object values is going to perform as well as anything else that is actually supported today (and it’s what game engines that support WASM currently use).

derefr 5y ago
> Last time I checked, all the abilities for directly manipulating JS reference types in WASM had yet to even be deployed outside of developer trials. Well, yeah, which means to me that we'd never try to do this today, but rather would do this once that sort of capability exists. (Just like the people who constantly propose multitenant Workers-like hosting within Erlang. Obviously it could work once sandboxing exists within the runtime, but that's not true today.) Note that the whole point of Firebase as a service/library—I picked this example for a reason—is to have a local live Javascript object graph whose state is synchronized over the network to a database somewhere; where you can walk it and read it and change it by doing regular Javascript things to it, as if it were a pure in-memory data structure. If you want to expose that in WASM, you basically need to expose it by exposing Javascript object manipulation semantics to WASM. (Not with WASM holding the objects itself, but rather like any "remote/distributed object" protocol, where WASM holds a handle that references an object, and makes syscalls for dereferencing-get, dereferencing-set, etc., passing that handle.) Without this, what you're exposing isn't really "Firebase" per se, but just a regular database that you send some sort of graph-manipulation queries to. And this is just one example among many of the sorts of arcane Javascript things where, if the hosting platform didn't allow them, then devs would find the hosting platform worthless and never engage with it. This is the whole point of the GGP poster's post. They weren't talking about sandboxing NaCl/ZeroVM-like "the code runs in a sealed ABI abstraction that only exposes the syscalls necessary to read the keyboard/mouse and draw to the screen" games. You can easily do that. It's been done. Developers didn't engage in any meaningful way—nothing like the takeup of Newgrounds. (Heck, it's downright simple to do one of these services yourself: pick an old game console with an HTML5 emulator implementation, e.g. one of the ones used on https://archive.org/details/internetarcade https://archive.org/details/internetarcade, as your abstract-machine runtime. Games, then, are arbitrary homebrew ROMs. Let people upload them; give them a customizable page that embeds them; wrap it in a trailer + payment-wall page ala itch.io if you like. Do fingerprint analysis to reject commercial ROMs. Done. This service could be built for a hackathon. Would anyone care to develop novel games for it? Pretty doubtful.) Instead, what the GGP was talking about sandboxing, is almost-but-not-quite arbitrary Turing machines. Because that's what the Flash games/apps posted to Newgrounds really were, and moreover what the modern track-every-click special-gatcha-for-the-thousandth-player-of-the-day variety always are. They use every capability a computer has, such that "sandboxing" in the sense of removing those capabilities doesn't make sense. You can't restrict what capabilities such programs have access to, without just denying the entire design the software is based around. You can only constrain how the game uses those capabilities. To put that another way: an SMTP server that doesn't let you send mail to certain large email hosting providers is effectively useless. But an SMTP server that doesn't let outgoing messages contain certain words (i.e. has an outbound spam filter) is quite useful. Restricting the what will just turn people away. Restricting the how has no such problem, since certain patterns of data-flow have no other use than to be nefarious. (If you're curious why I'm even talking about WASM at all, then, if I'm not proposing to take advantage of any of the sandboxing WASM offers: it's just because it's much easier to do your static analysis against a symbolic-execution implementation of bytecode VM for a bytecode ISA like WASM; than it is to do symbolic-execution of an interpreted language with complex syntax, like JS. But if you were willing to go down that route, you could totally static-analyze regular JS. Same safety guarantees, plus now the devs get to use regular JS and/or anything that interfaces with it—including the JS-subset textual form of WASM.)
- johncolanduoni 5y ago
  If you want the ability to manipulate a serializable JavaScript object graph without escapes static analysis is still overkill: a simple wrapper that only allows accessing enumerable own properties in the desired object tree works fine and seems a lot easier to get right, without blacklisting a lot of commonly used words in the JS API to avoid escapes. I’m really struggling to understand how making a sandboxed environment more “engaging” in a way that makes it more similar to Newgrounds-era flash that depends on this kind of thing at all. Newgrounds didn’t let you store data on their servers or anything. I suspect at the end of the day Flash had a good set of capabilities and a great authoring tool for making small games and animations, and there wasn’t anything more to it than that. I don’t remember any (non-malevolent) Newgrounds content that did anything more sophisticated with browser APIs than save stuff on local storage.

derefr 5y ago

> Last time I checked, all the abilities for directly manipulating JS reference types in WASM had yet to even be deployed outside of developer trials. Well, yeah, which means to me that we'd never try to do this today, but rather would do this once that sort of capability exists. (Just like the people who constantly propose multitenant Workers-like hosting within Erlang. Obviously it could work once sandboxing exists within the runtime, but that's not true today.) Note that the whole point of Firebase as a service/library—I picked this example for a reason—is to have a local live Javascript object graph whose state is synchronized over the network to a database somewhere; where you can walk it and read it and change it by doing regular Javascript things to it, as if it were a pure in-memory data structure. If you want to expose that in WASM, you basically need to expose it by exposing Javascript object manipulation semantics to WASM. (Not with WASM holding the objects itself, but rather like any "remote/distributed object" protocol, where WASM holds a handle that references an object, and makes syscalls for dereferencing-get, dereferencing-set, etc., passing that handle.) Without this, what you're exposing isn't really "Firebase" per se, but just a regular database that you send some sort of graph-manipulation queries to. And this is just one example among many of the sorts of arcane Javascript things where, if the hosting platform didn't allow them, then devs would find the hosting platform worthless and never engage with it. This is the whole point of the GGP poster's post. They weren't talking about sandboxing NaCl/ZeroVM-like "the code runs in a sealed ABI abstraction that only exposes the syscalls necessary to read the keyboard/mouse and draw to the screen" games. You can easily do that. It's been done. Developers didn't engage in any meaningful way—nothing like the takeup of Newgrounds. (Heck, it's downright simple to do one of these services yourself: pick an old game console with an HTML5 emulator implementation, e.g. one of the ones used on https://archive.org/details/internetarcade https://archive.org/details/internetarcade, as your abstract-machine runtime. Games, then, are arbitrary homebrew ROMs. Let people upload them; give them a customizable page that embeds them; wrap it in a trailer + payment-wall page ala itch.io if you like. Do fingerprint analysis to reject commercial ROMs. Done. This service could be built for a hackathon. Would anyone care to develop novel games for it? Pretty doubtful.) Instead, what the GGP was talking about sandboxing, is almost-but-not-quite arbitrary Turing machines. Because that's what the Flash games/apps posted to Newgrounds really were, and moreover what the modern track-every-click special-gatcha-for-the-thousandth-player-of-the-day variety always are. They use every capability a computer has, such that "sandboxing" in the sense of removing those capabilities doesn't make sense. You can't restrict what capabilities such programs have access to, without just denying the entire design the software is based around. You can only constrain how the game uses those capabilities. To put that another way: an SMTP server that doesn't let you send mail to certain large email hosting providers is effectively useless. But an SMTP server that doesn't let outgoing messages contain certain words (i.e. has an outbound spam filter) is quite useful. Restricting the what will just turn people away. Restricting the how has no such problem, since certain patterns of data-flow have no other use than to be nefarious. (If you're curious why I'm even talking about WASM at all, then, if I'm not proposing to take advantage of any of the sandboxing WASM offers: it's just because it's much easier to do your static analysis against a symbolic-execution implementation of bytecode VM for a bytecode ISA like WASM; than it is to do symbolic-execution of an interpreted language with complex syntax, like JS. But if you were willing to go down that route, you could totally static-analyze regular JS. Same safety guarantees, plus now the devs get to use regular JS and/or anything that interfaces with it—including the JS-subset textual form of WASM.)

johncolanduoni 5y ago
If you want the ability to manipulate a serializable JavaScript object graph without escapes static analysis is still overkill: a simple wrapper that only allows accessing enumerable own properties in the desired object tree works fine and seems a lot easier to get right, without blacklisting a lot of commonly used words in the JS API to avoid escapes. I’m really struggling to understand how making a sandboxed environment more “engaging” in a way that makes it more similar to Newgrounds-era flash that depends on this kind of thing at all. Newgrounds didn’t let you store data on their servers or anything. I suspect at the end of the day Flash had a good set of capabilities and a great authoring tool for making small games and animations, and there wasn’t anything more to it than that. I don’t remember any (non-malevolent) Newgrounds content that did anything more sophisticated with browser APIs than save stuff on local storage.