Read-only Top-level Classes
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
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:
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.
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 rational behind the change (or "bug fix", 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 concerns. What's the side effect of locking down these classes?
Cheers,
-- Nathan de Vries
[1] ejohn.org/blog/re-securing-json [2] www.ecmascript.org/es4/spec/incompatibilities.pdf