On Tue, Dec 8, 2009 at 7:59 PM, Oliver Hunt <[email protected]> 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 > validation, 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 > subsetting. 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 <http://www.eros-os.org/pipermail/cap-talk/2009-October/013567.html>, 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. -- Cheers, --MarkM _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
