On Oct 30, 2007 2:38 PM, Brendan Eich <[EMAIL PROTECTED]> wrote: > > Experiments such as Google > Caja<http://google-caja.googlecode.com/files/caja-spec-2007-10-11.pdf>are > interesting ( > discussion<http://www.nabble.com/Initial-draft-Caja-design-docs---library-now-available-t4611010.html>here), > and Mark Miller will (I hope) smite me mightily if I misspeak about > it, but as far as I can tell, such systems create an incompatible subset of > JS into which developers may "opt" -- not a successor standard for the > ECMAScript language that is backward compatible. Such a subset could be a > very good thing, don't get me wrong. But it does not fall neatly under TG1's > charter, because it's not backward-compatible, and profiled standards are > considered harmful. >
Hi Brendan, Your summary may well be accurate. I'm just confused about a few points of terminology I hope you might clarify: Caja is approximately a subset of ES3, much as JSON is a subset of ES3, and ES3 is approximately a subset of the ES4 proposal. ADsafe is also approximately a superset of JSON and a subset of ES3. We have yet to understand well (or decide) the degree to which ADsafe is a subset of Caja. AFAIK, the only subset relationships here with unqualified compatibility are JSON < ES3 and JSON < proposed ES4. All the others have hazards that programmers need to understand in order to make use of the subset relationship. In this sense, the situation is analogous to C being approximately a subset of C++: When writing a correct C program, if you know what hazards to avoid, it isn't much harder to write it (without ifdefs) so that it's also a correct C++ program. Although many may prefer C to C++, no one would propose C as a successor to C++. Nevertheless, it's valuable to both communities to maintain this almost-compatible-subset property between the languages. Likewise, it would make no sense to propose Caja as a successor to ES3. So, depending on what you mean, I might argue with your phrase "incompatible subset". We are seeking to create, as close as we possibly can, a compatible subset. If you see a way in which we could be more compatible while still meeting our other goals, please let us know. Thanks. Also, could you explain the phrase "profiled standards"? Thanks. > Anyway, it's early days for Caja and other such systems. If TG1 continues > to function, it should definitely harvest good ideas from it, and stand on > shoulders, not toes. > Thank you. I will read the ES4 proposal carefully and let you know what shoulder and toe issues I find. > We've pressed Doug Crockford on this point and heard nothing in the way of > concrete proposals, save for a small one I championed at the last > face-to-face meeting (a better-isolated String.prototype.evaluate() taking > a scope object). But that went nowhere for lack of effort -- I half expect > it to turn up in "Microsoft's vision for ECMAScript", which would make a > fork in the standard. I'll still try to rescue it for ES4, but it's just a > small isolation device, good to have, but not nearly enough for "Security" > with a capital S. > I would like to hear more about this. A safe eval primitive that provides good isolation could actually be a very powerful lever for expressive security. Chapter 10 of <http://erights.org/talks/thesis/> tries to explain some of the relevant issues. Unfortunately, this is the most confusing and badly written chapter of that document, and badly needs a rewrite. If you do wade into it and find it confusing, please do not hesitate to ask me to clarify. -- Text by me above is hereby placed in the public domain Cheers, --MarkM
_______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
