What is the current status of SES, tinySES and Jessie?

I have questions
1

I'm discovering SES, and the adjascent projects, tinySES and Jessie, which all seem interesting in their own right.

I'm a bit puzzled by the state of the affairs though. The TinySES repo I could find points to this fork as current, but that link is actually a redirect to Jessie, which itself looks inactive.

On top of that the Google Caja project which relied on SES has been archived...

Endo, a SES implementation, looks alive, but the spec itself has been idle for a long time.

Is the TC still interested in any of these projects? TinySES was the most promising AFAI'm concerned, but it looks dead, even though there are still references to it in the Jessie docs.

2

There are regular SES meetings that are recorded and uploaded. Lots of interesting conversations happening!

1 Like
3

Many thanks! That's pretty good to know.

So, am I correct that TinySES and Jessie are not handled by the TC at the moment, but they are personal projects of TC members ?

4

Oh, I see the Jessica architecture has been discussed recently at a meeting :-) Edit: oh, not so recently, the playlist is backwards timewise...

5

Thank you for inquiring about SES, or as we among the champion group have been calling it recently, “Hardened JavaScript”. I can offer a snapshot of the status of some SES proposals.

In summary, please look to the Endo and Moddable/XS repositories for practical vetting of Compartment, lockdown, and harden, from which we intend to update our proposals. Please join the SES strategy meetings to participate in the evolution of these and related proposals. Please anticipate joining the TC39-TG3 meetings, since this will be the first group to hear proposal updates.

The SES proposal is very stale and reflects an earlier state of the SES architecture which resulted in the recent advancement of Shadow Realms. The champions have pivoted and the next planned action is to work toward advancing the Compartment proposal. We intend to reduce the Compartment proposal to provide the missing JavaScript module loader API and nothing more.

Then, we intend to rearchitect the SES proposal under the moniker Hardened JavaScript, which will cover two coupled language features: Lockdown and Harden. Lockdown is a function that transforms the current JavaScript realm into a Hardened JavaScript realm. Lockdown makes some modifications to the graph of language intrinsics including the creation of a subgraph of “shared frozen intrinsics” that can be safely shared by multiple compartments.

The champion group has most recently focused on vetting the API’s we intend to propose, in the “ses” shim (in the Endo repository) and the XS JavaScript engine. Moddable and Agoric have been collaborating to implement Compartments and other proposals, converging these implementations so that we can be sure that the proposal is implementable both as a shim and native code.

In the Endo repository, we go on to demonstrate practically that we can use Compartments to virtualize a module loading behavior that is consistent with Node.js packaging conventions and capable of supporting third-party module records for CommonJS and WASM, for example. It is necessary for Compartments to be able to virtualize the host behaviors of both Node.js, the web, and embedded systems like XS, since the module specification does not provide these opinions, so we have carefully designed Compartments to separate concerns like module specifier referrer resolution and import.meta. XS verifies that Compartments are coherent with top-level-await. We expect to need to do more work to verify that they are coherent with import assertions.

This new architecture frees Compartments to advance as a generally useful tool, not just for hardened JavaScript but also for implementers of bundlers, import mappers, test scaffolds, and plugin ecosystems. Then, the Lockdown and Harden proposal treats Compartments as evaluators, just as with Function and eval. After Lockdown, each Compartment has its own Compartment, Function, and eval that are isolated to that compartment, though all of these share the same frozen intrinsic prototype.

At Agoric, we’ve explored using Jessie as a language subset that’s enforced with a linter to make certain programs easier to review or audit. Jessie is analogous to JSON. If it is successful as a compiler target in the wider language community, I can imagine many years from now proposing the inclusion of a Jessie language subset evaluator to the language.

6 Likes
6

As another lurker: thanks a lot for the concise recapitulation of the current state! It's a bit hard to follow what's going on in that area without being deeply involved.

This sounds great!

1 Like
7

Thanks for the update @kriskowal . I probably will not have the time to attend the meetings, but thanks for the invitation !

8

@kriskowal Tnx for the update above

Been looking into SES recently and only now discovered your post, which clarifies a lot :-)

Maybe an idea to do a quick update to endo/README.md at a311acb02115271fbda6953734d0b4f52aa85892 ¡ endojs/endo ¡ GitHub and GitHub - tc39/proposal-ses: Draft proposal for SES (Secure EcmaScript) with a pointer to this discussion/your post? Think that would help out people getting into SES nowadays a lot

9

Regarding the explanation of the current state of SES: it is mentioned that the recent advancement of Shaddow Realms is related to earlier state of the SES architecture, from which I'm deducting that Shadow Realsm are now considered as a stepping stone towards SES/Hardened JavaScript, correct?

If so, then curious how exactly: with Shadow Realms being about creating new realms, each with new instances of all global/intrinsic objects and Compartments gravitating towards 'just' being an additional api to gain control over module loading, where exactly will for example the freezing of intrinsics occur and how will those frozen intrinsics get used in 'child' realms, so the identity discontinuity issue is solved?

The documentation at endo/packages/ses at master ¡ endojs/endo ¡ GitHub seems to suggest (to me at least) that that is behavior inherent to creating Compartments, but I think the latest Compartment proposal doesn't imply that.

If the freezing of intrinsics and using those frozen intrinsics on shadow realms is something that the lockdown method does AFTER creating the shadow realm, whould that mean that creating a shadow realm is creating new instances of the intrinsics, only to be thrown away when the lockdown method is called on the shadow realm instance?

Or does calling lockdown in the parent realm cause all (newly created) child realms to automatically get the shared intrinsics?

Anyway: just trying to understand the new approach (to my knowledge there isn't any documentation of the new 'Hardened JavaScript' approach anywhere, correct? There's the shadow-realms proposal and the (updated) compartments proposal, but I haven't been able to find a proposal for the lockdown and harden stuff (that would be on top of the previous mentioned two proposals).

If there's a better place to ask these questions, I'm all ears, as I've also got questions about whether Date.now()/new Date() could be made safe by for example lowering their resolution to say seconds in cases where third party code does need to the current datetime.

Also, @kriskowal mentioned the SES strategy meetings: besides the video's, is there any info on there anywhere, like schedule, agenda and notes? Couldn't find any (quickly), except the video's

10

ShadowRealm is useful but orthogonal to Hardened JavaScript. The ses package in npm is what we are calling a Hardened JavaScript shim at this point. It includes everything necessary to harden a Realm, including a ShadowRealm. Every compartment in a realm shares the same batch of intrinsics, but within the compartment, evaluated code and modules can only see the subset of shared and frozen intrinsics and any other objects they have been endowed. So, still one batch of intrinsics per realm but unique evaluators per compartment.

We are currently engaged with a the new “Modules Harmony” group at TC39 to take the part of the compartments proposal that pertains to module loading and getting that integrated into the language along with related proposals for module blocks, module fragments, and deferred module evaluate, all in a way that must be harmonious with the web’s content security policy model in addition to providing a suitable foundation for implementing Compartment, Lockdown, and Harden in user code.

The map is not the terrain, so I won’t speculate on what will come of module harmony at TC39, but I do think we’re finally going to get the missing module loader in one form or another. We will probably decouple a proposal for reifying ExecutionContexts. Compartments can be implemented in user code given a module loader API and separable execution contexts.

The TC39 proposal for Hardened JavaScript nĂŠe SES remains at Stage 1 and will need to be updated to reflect all the new foundations we will have to work with.

3 Likes