Read-only Top-level Classes

[Brendan Eich]

On Dec 10, 2007, at 6:36 PM, Nathan de Vries wrote:

> Hi there,
>
> I was just reading John Resig's recent article titled "Re-Securing
> JSON" [1], and was wondering how this would affect ECMAScript 4. This
> led me to the "Compatibility Between ES3 and Proposed ES4" paper [2],
> which makes reference to the rationale behind the change (or "bug  
> fix",
> as it's referred to).

See also

https://bugzilla.mozilla.org/show_bug.cgi?id=376957#c50

et seq.

> It strikes me as somewhat non-obvious that a top-level, self-hosted
> class in a meta-programmable language is read only due to security
> concerns.

Reflection kills theorems for free -- reflection plus mutation can do  
even more damage. TANSTAAFL still applies, however you balance meta- 
programming and integrity. We're trying to make the ES3 spec coherent:

http://wiki.ecmascript.org/doku.php?id=clarification:which_prototype

and beef up the integrity of standard constructors (in ES4 these  
become properties denoting types).

As noted, the security concern is only a desire for defense in depth  
-- a defensive measure. Obviously CSRF wouldn't work on JSON-served  
services if they authenticated carefully. But stuff happens.

> What's the side effect of locking down these classes?

The side effect? Not sure, we're finding out in Firefox 3 beta 2. The  
direct effect is understood in the abstract, but only large-scale  
spidering and testing will tell more about what concrete web JS  
expects and demands. Given the incoherence in ES3 and implementations  
in the field, we think this won't break cross-browser content. More  
when we know more.

/be



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20071211/474ef85a/attachment-0002.html