Fwd: proposed relationships of Secure EcmaScript, ES3.1, and ES4.

Mike Samuel mikesamuel at gmail.com
Wed Feb 20 18:10:20 PST 2008


Resending after adding myself to es4-discuss.


On 20/02/2008, Mark Miller <erights at gmail.com> wrote:
>
>
> [+es4-discuss]
>
>
> On Wed, Feb 20, 2008 at 4:59 PM, Mike Samuel wrote:
> > On 20/02/2008, Mark Miller wrote:
> > Since a language is commonly defined as the set of strings produced by a
> > particular grammar, is this equivalent to
> >
> >     JSON ⊂ ADsafe ⊂ Cajita ⊂ Caja ⊂ ES3 ⊂ ES4
>
>
> People who know Unicode are dangerous ;). How did you type that?
>
> Syntactic subsetting is implied but is not the main intent.
>
>
>
> >  or does your inequality imply some semantic relationship such as:
> >     The same string evaluated in an expression context produces an
> > "equivalent" result assuming no exceptions thrown.
> >     The same string evaluated in a statement context has "equivalent"
> > side-effects assuming no exceptions thrown.
> >  ?
>
>
> We need to consider each individually. Ideally, once relationships are
> repaired
>
> 1) Any legal JSON text can be evaluated as a program in any of the
> languages to its right.
> * This had not been the case for JSON / ADsafe because of the severity
> of the ADsafe blacklist, which Crock has now repaired.
> * This is not the case for JSON / (Cajita or Caja) because of Caja's
> current prohibition on names ending in double underbar. However,
> Caja's restriction is an implementation artifact of the need to
> translate Caja to ES3. Given appropriate changes in ES3.1, we may be
> able to remove that restriction from Caja/Cajita-on-ES3.1/ES4.
> * Could you explain the difference in Unicode newline rules that
> prevents JSON from being syntactically a subset of ES*? Thanks.


There's three problems according to my reading of
http://www.ietf.org/rfc/rfc4627.txt but only the first is directly related
to syntax:

(1) There are JSON programs that are not valid ES programs.
The JSON program [ "\u2028" ] where the unicode escape is replaced with its
literal equivalent is valid according to JSON since the set of characters
that can appear in a string unescaped is

unescaped = %x20-21 / %x23-5B / %x5D-10FFFF

but ES does not allow codepoint 0x2028 or 0x2029 to appear unescaped in a
string since they are newline characters.

(2) There are JSON programs that have the same text as ES programs but
different meaning.
ES262 says that all format control codepoints, such as 0x200C, should be
stripped out of the program in a pre-lex phase.  This is not consistently
implemented:
    eval("'\u200c'.length") == 0 on SpiderMonkey, and 1 on most other
interpreters
JSON does not strip these characters out, so they are treated as
significant.

(3) There are JSON programs that can be parsed to ES but that cannot be
serialized back to JSON without losing track of where info was lost.
JSON does not put any limits on numbers, but ES does.  ES will treat 1e1000
as Infinity.  Since JSON does not have a value Infinity, it is unclear how
to implement toJSON(fromJSON("[1e1000]")).

cheers,
mike


* There is currently a conflict between JSON and ES3 regarding Unicode
> Cf characters. I believe this is repaired by ES4. I do not know, but I
> hope that this is repaired in ES3.1 as well. If so, then Caja and
> Cajita will inherit this repair.


* The legal JSON string '{"__proto__": 3}' cannot be correctly
> evaluated as a JavaScript program on Firefox. In fact, it cannot even
> be correctly unserialized by a JSON library. I don't think this can be
> repaired. This is an example of a subset gotcha in theory that
> probably makes no practical difference to anyone.
>
> 2) The relationship between ADsafe and Cajita is complex and evolving,
> and should be discussed in a separate thread.
>
> 3) Cajita is, and should remain, a statically checkable subset of
> Caja. Given a Caja program, one can statically determine whether it is
> a Cajita program. Any valid Cajita program is a valid Caja program of
> the same meaning. Cajita uses the Caja runtime.
>
> 4) Caja is (ideally) a fail-stop subset of ES3. The "ideally" is
> modulo the gotchas listed in the Caja spec, some of which will
> hopefully be repaired as Caja and ES3.1 evolve. As the Caja spec
> explains, "fail-stop" is a bit broader than "assuming no exceptions
> thrown". It is "assuming no failures are reported". The difference is
> exactly that, in order to support the JavaScript feature-test pattern,
> reading an absent property reports failure by returning undefined
> rather than throwing an exception. Properties not enabled by the Caja
> whitelist can thus be considered absent to Caja without violating
> either the fail-stop notion or normal JavaScript expectations.
>
> As for the subsetting relationship between ES3.1 and ES4, I believe
> that everyone involved in both efforts intends this relationship to
> hold. I hope they succeed. Hmmm. I suppose "they" is now "we" ;).
>
>
> --
>
> Text by me above is hereby placed in the public domain
>
>   Cheers,
>   --MarkM
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to
> http://groups.google.com/group/google-caja-discuss
> To unsubscribe, email google-caja-discuss-unsubscribe at googlegroups.com
> -~----------~----~----~----~------~----~------~--~---
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20080220/fedb7002/attachment-0002.html 


More information about the Es4-discuss mailing list