JS ShadowRealms / Compartments / Secure ECMAScript (SES)

[robertlong]

@ashconnell posed a question in our intro discussion that could use its own discussion. Why pick WASM? Why not sandbox JS with Javascript ShadowRealms / Secure ECMAScript (SES)?

Link to the ShadowRealm proposal
Link to the SES Proposal
Link to the Compartments Proposal

I've experimented with this sandboxing method a bit myself. It's a really interesting and clever way of sandboxing in an existing Javascript environment. I first heard about it through the folks over at Agoric and attended a meetup where I spoke with them in person. They've been very persistent in trying to get Realms adopted as a TC39 proposal and it's been encouraging to see their progress there. At the time of this post, it is currently in Stage 3 of the TC39 process and has a pretty good chance of making its way into some web browsers / JS engines.

I may be wrong with this, but I think Compartments and Secure ECMAScript haven't made nearly as much progress. But as I understand it, it can be implemented on top of ShadowRealm and may not need to exist as an official TC39 spec?

What are ShadowRealms?

From the ShadowRealms explainer:

The ShadowRealms proposal provides a new mechanism to execute JavaScript code within the context of a new global object and set of JavaScript built-ins.

The API enables control over the execution of different programs within a Realm, providing a proper mechanism for virtualization. This is not possible in the Web Platform today and the proposed API is aimed to a seamless solution for all JS environments.

Essentially, you get a sandboxed execution environment where you can execute some Javascript code. You can extract the return value and you can execute code inside that environment, but it doesn't give you a way to expose interfaces securely.

Secure ECMAScript (SES) / Compartments

Exposing interfaces / APIs is where SES comes in. You may want to be able to provide an API from the host to this sandboxed environment. Well how do you do so without accidentally exposing the host app? Javascript is a prototypical language and by walking up the prototype chain you can likely break out of this sandbox. SES is a proposal for a set of APIs that let you do just that and Compartments were a concept of SES that were extracted from the spec and turned into a more digestible proposal.

As far as I can tell the last remaining bit of SES not contained within the Realms and Compartment proposals is the Realm.lockdown() method which lets you freeze the realms/compartments and prevent prototype poisoning. My knowledge of how all of this works is fairly basic and dated so please correct me if I got any of this wrong / oversimplified.

So why WASM?

In my opinion, we should be focusing on portability, security, and performance, in that order. Javascript is one of the most popular programming languages in the world. Only supporting JS wouldn't be a huge hit to portability in general. However, within the 3D graphics / games field, JS has a relatively small market share. C++ is the most popular language, but many others are in use. So, IMO, WebAssembly would be the best building block for portability. Not only can you use the programming language you are most comfortable in, you can likely use some of your existing libraries / tools. Performance in WASM can be significantly better than JS. It's mostly based on how you manage memory, but seeing how we write code in bitECS to get around JS's performance limitations, it's not like the JS most people write. That brings us to security, SES is battle tested at Salesforce, however Figma didn't quite have the same confidence in the tech when it first came out. WebAssembly on the other hand is becoming the de-facto runtime environment at companies like Fastly, Cloudflare, and others for serverless / edge compute.

There are definitely pros/cons with each solution. I guess the decision should really come down to what we can agree on. Personally, I'm uncomfortable with the current state of SES. It's too early to tell if it is secure enough to trust in our applications. In Third Room, a security breach could mean exposing data that is otherwise end to end encrypted. It's also very important to me to integrate into the workflows of game industry veterans. If we want to see great content built for the metaverse, we need people who know how to build great content. I haven't seen the same level of enthusiasm for JS outside our web development bubble.

Let me know what you all think on this matter. Regardless of the situation, this tech is super interesting and I'll definitely keep my eye on it!

[robertlong]

I should also mention that there's nothing stopping us from taking Figma's route for sandboxing and running FastJS in WASM. Perhaps down the line, there will be an even smaller and faster JS engine for WASM. There is an outstanding GC proposal to keep an eye on.

[ashconnell]

Great overview.

Just to clarify, the Agoric people mentioned to me that Figma used the older architecture of Realms and Membranes, which was a lot harder to defend for.

The new compartments and harden() flow is much more secure to build on, and I’m yet to find a single flaw in its implementation.

I tend to agree that WASM is likely to be more secure and performant, with the caveat of a higher barrier to entry.

For my own metaverse tech I definitely prefer to stick to a familiar DX that most devs are already using, namely React, but using compartmentalised subtrees.

[robertlong]

Gotcha, yeah, definitely something to bring up at the meeting. I think that's an awesome and very interesting design for sandboxed UGC. I'm personally a big fan of React and think React Three Fiber is a very cool project. However, I don't think I'd be interested in building a UGC standard around that concept. Perhaps we can come up with something that is compatible, but it's a long ways off from the low level API I've been pushing for in this space. I'd ideally like to find a middle ground for the Godot, Unity, and Three.js folks we have here in this group so far.