Another de-facto insecurity we need to fix in ES5

Maciej Stachowiak mjs at
Wed Jun 17 19:10:16 PDT 2009

On Jun 17, 2009, at 3:34 PM, Mark S. Miller wrote:

> 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).
> Google is quite active in TC39. Google's representatives to TC39  
> (including me) are now in close coordination with our v8 team.  
> However, v8 remains committed to following WebKit. Fortunately,  
> AFAIK, WebKit has not yet taken any stance on whether [[Prototype]]  
> will be mutable in their ES5 implementation. Maciej?

Your phrasing of the question strikes me as odd, because changing  
behavior of de facto extensions like this seems orthogonal to  
supporting a new version of the spec. If getting rid of or restricting  
mutable __proto__ turns out to be feasible and a good idea, then we  
would not tie it to implementation timeline for ES5 features.

As to the substantive issue: mutable __proto__ is something we would  
prefer not to have, but we are concerned about the compatibility  
issues. We look forward to hearing about Mozilla's experience with  
changing it.

Personally, I think leaving "distasteful" but cross-browser features  
like this out of the spec in the hopes that they will wither away from  
neglect is a poor approach. If browsers feel pressured to implement  
such extensions for Web compatibility then we are not doing anyone any  
favors by leaving them in the domain of mutual reverse-engineering. I  
would prefer to see such features explicitly specified (with suitable  
restrictions) or explicitly forbidden, and perhaps explicitly  
deprecate them with the plan for further limits or outright removal in  
future versions of the spec. But it seems too late to make big changes  
in this regard for ES5. Maybe in the next version.


More information about the es5-discuss mailing list