Re: Another de-facto insecurity we need to fix in ES5

For ES5, this is a tempest in a teapot.

We at Mozilla are trying to remove assignable __proto__ in a near-term release,

except in these two useful and (AFAIK) safe cases:

* A newborn with no other properties.

* A recent-born in the midst of initialization via evaluation of its object initialiser syntax, where the baby object can't escape, can't be referenced to make a cycle, etc.

We really don't want to continue supporting mutating __proto__ in other cases. Assignable __proto__ is a hugely expensive operation that breaks all sorts of optimizations, requiring fairly expensive deoptimization effort.

ES5's Object.create relieves the need for any of this, but legacy code won't be rewritten all at once, so we're probably going to support the above two bulleted cases.

The idea that the ES5 spec suddenly makes the world more secure by trying circuitously to address old extensions such as __proto__ seems optimistic to me. Better to get rid of the offending extension than try to fence it while not speaking its (I mean ES-unspecififed __proto__'s) name.

But this is a job for implementors, not the spec. Implementors jumped in when the standards process stalled after ES3. Blame them for trying, or failing to design high-integrity APIs, but it's all spilled milk. They need to clean it up, 'sall (I say this as one of "them").

The bigger picture must involve implementations as well as the spec, and de-facto standards that may precede de-jure replacements or adoptions of de-facto standards. It isn't as if ES5 is the last time there will be a de-facto mess to clean up, although members of the committee are making good promises and progress in sharing intentions and prototypes.

I suspect we'll see some de-facto stuff come out of one or two vendors who aren't active in TC39 (Apple, Google V8).

Beyond this point, implementations will have bugs, whether in would-be de-facto extensions to the standard, or in standardized components -- forever. Attempts to inject security by code transformations (which of course can themselves be buggy) will simply have to try to work around browser JS engine bugs.

Security is never done, because it consists of end-to-end and many-layers property enforcement problems, where the evolving system and economic scarcity mean the bad guys always have a new layer or middle-man that's under-defended to attack. Denning said this in her 1999 Infosec award speech, and it seems unassailable, even if it outrages some of my academic research friends.

Better JS security will have to come from the browsers fixing bugs and breaking compatibility, where the alternative is an ongoing security hazard that's actually exploited. When it comes to both bad old default security policies, and some of the extensions added over the years, I say: break the web, or at least bend it! My new mantra. Shocking, I know, but with minority-share browsers now getting close to modern-IE by-version market share, isn't it time?