AST in JSON format
Mark S. Miller
erights at google.com
Tue Dec 8 20:51:45 PST 2009
On Tue, Dec 8, 2009 at 7:59 PM, Oliver Hunt <oliver at apple.com> 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.
> Realistically you would want the browser to be responsible for
> validation because it is able to do much more interesting forms of
What are these more interesting forms of validation?
> there are in fact already multiple concepts being investigated by
> the whatwg to solve just this problem, without requiring js
What are these other concepts? I am aware of one -- the sandboxed
iframe. Compared to JS subsetters, this is flawed in many ways. But
the more important contrast is that whatwg is investigating security
frameworks to be centrally designed, by them/us, and then implemented
and deployed by the browser makers. When they screw up, the rest of us
downstream have no recourse. By contrast, multiple competing projects
are trying various approaches to JS subsetting -- Caja, FBJS, MS
WebSandbox, ADsafe, Jacaranda. By one measure
these already dominate the Same Origin Policy as the primary isolation
mechanism on the web.
This victory happened despite the insane difficulty of doing this on
an ES3 base. Again, starting from ES5, this becomes vastly easier.
> Especially given in the mashup scenario you don't just have JS,
> you have the DOM and html -- assuming you can completely
> separate html from the js, you're still fairly limited as your
> validation either prohibits any access to the dom or the validation
> can be circumvented.
All the JS subsetters mentioned above mediate access to the dom but do
not prevent it. The virtualized dom provided by Caja is a sufficient
emulation of the browser DOM that the YUI library from Yahoo! now
operates fully cajoled (translated by Caja and accessing the dom only
via Caja's mediation). Please show how the protections provided by
Caja can be circumvented.
More information about the es-discuss