> 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, 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.)