AST in JSON format

Mark S. Miller erights at
Sat Jan 9 22:01:45 PST 2010

On Tue, Dec 8, 2009 at 8:51 PM, Mark S. Miller <erights at> wrote:

> On Tue, Dec 8, 2009 at 7:59 PM, Oliver Hunt <oliver at> wrote:
> > Providing an AST doesn't get you anything substantial here as
> > the hard part of all this is validation, not parsing.
> Given ES5 as a starting point,
> 1) validation for many interesting purposes, especially security, is
> no longer hard,
> 2) the subset restrictions need no longer be severe, and
> 3) the issue isn't what's hard but what's slow and large. Lexing and
> parsing JS accurately is slow. Accurate JS lexers and parsers are
> large. Even if JS is now fast enough to write a parser competitive
> with the one built into the browsers, this parser would itself need to
> be downloaded per frame. Even if all downloads of the parser code hit
> on the browser's cache, the parser would still need to be parsed per
> frame that needed it (unless browsers cache a frame-independent parsed
> representation of JS scripts).
> I am currently working on just such a validator and safe execution
> environment -- assuming ES5 and a built in parser->AST. Going out on a
> limb, I expect it to have a small download, a simple translation, no
> appreciable code expansion, and no appreciable runtime overhead. Once
> I've posted it, we can reexamine my claims above against it.
Work in progress is at <>.

This SES implementation is not actually quite complete yet. Even once it
seems complete, we can't test it until there is an available ES5
implementation we can try running it on. However, it is complete enough that
we're more confident about what it will be, once bugs are fixed, that we can
try assessing the limb I climbed out on above. Though, until it is tested,
all this should still be taken with some salt.

* SES can all be implemented in any ES5 implementation satisfying a few
additional constraints that we're trying to accumulate at <>.

* The implementation sketch shown there depends on two elements not
currently provided by ES5 or the browser:
    * A Parser->AST API, for which Tom wrote an OMeta/JS parser at <>
that does run in current JavaScript, producing the ASTs described at <> and available at <>.
   * An object-identity-based key/value table, such as the EphemeronTables
from the weak-pointer strawman. Assuming tables made the SES runtime
initialization a touch easier to write. But I can (and probably should)
refactor the SES runtime initialization so that it does not use such a
table, just to see how adequate ES5 itself already is at supporting SES.

* Given a parser, the rest of the SES startup is indeed small and fast. For
an SES in which the parser needs to be provided in JS, the parser will
dominate the size of the SES runtime library. The SES verifier is really
trivial by comparison with any *accurate* JS parser.

* We are enumerating the subset restrictions imposed by SES at <>. For JS code that is
already written to widely accepted best practice, such as no monkey patching
of primordials, I would guess these restrictions to be quite reasonable.
This is the area where we need the most feedback -- is there any less
restrictive or more pleasant object-capability subset of ES5 than the one
described here?

* Because this SES implementation is verification-based, not
translation-based, there is no code expansion.

* SES does no blacklisting and no runtime whitelisting. It does all its
whitelisting only at initialization and verification time.

* Aside from "eval", "Function", "RegExp.prototype.exec",
"RegExp.prototype.test", and initialization of the SES runtime (which, given
a built-in parser, should be fast), SES has *no* runtime overhead. This also
applies to "eval" and "Function" themselves. All their overhead is in
starting up. Given a fast parser, this startup overhead should be small.
After startup, code run by either eval or Function has no remaining runtime

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list