proposal-ses

There is some effort to standardize something along these lines. Well, some things which combined would achieve this. It’s too late to bake it into ESM, but I believe it’ll be possible with ShadowRealms[1] and/or SES[2], and Built-in Modules (JS STL)[3]. 1: https://github.com/tc39/proposal-shadowrealm 2: https://github.com/tc39/proposal-ses 3: https://github.com/tc39/proposal-built-in-modules

Doesn't SES address that? The only fundamental barrier right now seems to be performance, which could be addressed by runtime support. https://github.com/tc39/proposal-ses https://github.com/endojs/endo

There is a proposal to add OCaps on a language level in TC39[0]. There is a drop-in implementation which already works in both Nodejs and browsers[1]. As a developer who wants to sandbox your own (recursive) dependencies, this is wrapped and made accessible today in Lavamoat[2]. Basically a package or app can provide a policy manifest specifying which capabilities (e.g. network or filesystem access) should be granted for each sandboxed dependency. Also comes with a tool that will auto-generate a starting point from your existing dependency tree. IMO this is the future. Currently Lavamoat does come with a performance penalty but hopefully this idea will catch on and make it into language runtime implementations. Lavamoat is still marked as "preprod" on npm but talking to the original author, the API is practically stable and it will shortl

Fairly certain you don't want to be throwing `eval` in your code. I'm also building a workflow engine on the side, but don't want to see you run into security issues :) Look into the realms TC39 proposal, the SES TC39 proposal, or running (no joke) a lightweight ES6 environment in webassembly to eval your code. https://github.com/tc39/proposal-realms/#ecmascript-spec-pro... https://github.com/tc39/proposal-ses https://github.com/justjake/quickjs-emscripten

This has been my feature work for the past couple months (I work on an enterprise site builder, basically, with some users doing what you describe -- we need to support that but hopefully with a smaller/harder to misfire footgun). There's a lot of feature complexity even after you've simplified it down, and it's kind of maddening how much effort it is to just send an extra (correct for the context) string in the response headers. The spec versions are interesting to read too, as well as browser compatibility. Differences in interpretation of the spec lead to github issues which lead to browsers fixing things in the past few months that have been part of the spec for much longer. (And if you have a big chunk of IE11 users, "what's the point" is valid.) An example of a spec issue is that I'm working on adding an endpoint for the report-uri

Right. Access to the environment is the dangerous part, not the eval function. There's a proposal to tame the JS global environment along those lines: https://github.com/tc39/proposal-frozen-realms Note however that the threat model here does not include denial of service. You have to address that at another level like OS processes or E vats.

I don't know its current status with the committee, but https://github.com/tc39/proposal-frozen-realms proposes something equivalent to Caja for modern JS. It can be a lot simpler now because ES6+ is much closer to what's needed than JS was when Caja was made.