[TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

[Mark Miller]

On Oct 30, 2007 2:38 PM, Brendan Eich <brendan at mozilla.org> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20071030/5003231a/attachment-0002.html