"Still under development: do not use for production systems yet, there are known security holes that need to be closed."
Also note the experience of Figma who used the realms shim I think this project is using to secure Figma's JS based plug-ins system, only to promptly take a different approach when compromises were identified:
"Since we published this blog post, we decided to change our sandbox implementation to an alternative approach: compiling a JavaScript VM written in C to WebAssembly"
That's a fairly good indictment of browser sandboxing :)
I've had a few arguments with the person who leads SES over the past couple years, stemming from the idea that the realm shim is able to be attacked by new language features it doesn't know about. (for example, dynamic import exposing the outside environment).
I'd probably stick to a WASM VM unless JS exposed the ability to spin up a separate VM like that on its own (which is very unlikely to ever happen).
The original SES doesn't seem to do anything to prevent meltdown/spectre attacks [1]
This version removed direct access "Date" [2] but I'm not sure I'd trust any code running in the same process space given how hard it is to fix spectre in general.
What I really want is a JavaScript API--doesn't need to be a "VM": just a wrapper for an existing one--that makes it trivial to manipulate JavaScript engine spaces but where instead of them merely being separate memory allocators (as would be the case if you allocated two JavaScriptCore runtimes or engines or whatever they were called) the code is run in a separate process that doesn't contain any others memory or information and all communication with it is done via some kind of IPC (which you would then minimize using).
Spectre relies on being able to speculatively access data and extracting information about said data through a side channel despite the speculative execution not committing. A separate process means address spaces are separate, which means speculative execution cannot access the data.
Meltdown is similar, but because a CPU affected by Meltdown does not perform permission checks during speculative execution, you can read memory that the execution environment doesn't even have permissions for. E.g. kernel memory.
The fix for Spectre is thus to only consider address spaces a security boundary; interpreters or JITs cannot be considerd security boundaries any more (in general).
FYI, Moddable's XS JavaScript engine already includes a native preliminary implementation for anyone who wants to play. As a contributor to the standard, their announcement post is also interesting: https://blog.moddable.com/blog/secureprivate/
> SES is not a security model or a security policy. SES is a way to build these using standard JavaScript. By taking this more general approach, SES allows each host to define its own approach to security (including the option to have no restrictions at all). This is important because a security policy that makes sense for scripts running on a lightbulb is unlikely to apply equally well to scripts running on a web server or scripts in a web page. SES provides tools in the language to build secure systems, but it is not a security system.
I've been playing with this, exploring its potential for running user scripts.
As noted in another comment, Figma used a Realms polyfill for their plugins, similar to SES, then migrated to using WASM-ized QuickJS as a safer sandbox.
Also note the experience of Figma who used the realms shim I think this project is using to secure Figma's JS based plug-ins system, only to promptly take a different approach when compromises were identified:
https://www.figma.com/blog/how-we-built-the-figma-plugin-sys...
https://www.figma.com/blog/an-update-on-plugin-security/
I am looking forward to Realms. Until then, I am doubtful of attempts to fully secure third party JS execution in the browser's engine.