Read-only Top-level Classes
brendan at mozilla.com
Tue Dec 11 15:35:15 PST 2007
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" , and was wondering how this would affect ECMAScript 4. This
> led me to the "Compatibility Between ES3 and Proposed ES4" paper ,
> which makes reference to the rationale behind the change (or "bug
> as it's referred to).
> 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
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:
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Es4-discuss