Another de-facto insecurity we need to fix in ES5

Brendan Eich brendan at mozilla.com
Thu Jun 18 01:20:39 PDT 2009


On Jun 17, 2009, at 9:54 PM, Allen Wirfs-Brock wrote:

> I agree that it is problematic to spec. things related to extensions  
> that are not part of the spec. In this particular case I wouldn't  
> talk about __proto__ at all. What I would do is specify that the  
> value of an object's [[Prototype]] internal property many not be  
> modified if the value of its [[Extensible]] property is false.

As I just wrote in reply to Mark, I'm good with this.


> BTW, I haven't yet perceived that we have consensus on putting this  
> into ES5.  My interpretation of  Brendan's initial comments on the  
> matter was that he was opposed to it for ES5.  (I'm sure he'll let  
> us know whether or not that is correct).

It's late in the game, but a sentence about [[Prototype]] seems  
doable. I defer to you on this, since you're Editor and it'll fall  
upon you to draft the change.


> Personally, while it is a quite plausible embellishment of what we  
> already have specified, I think it is very late for such additions  
> and I'm somewhat skeptical of the actual impact of such prophylactic  
> requirement on implementers who think they have a good idea that  
> collides with the restriction.

This was where I voiced more general skepticism about "security", but  
we can still fix what's known to be broken, if there's time. And I  
foresee no problem for implementors or developers with new ES5 APIs,  
all of which are "opt in", breaking assignable __proto__.

/be


More information about the es5-discuss mailing list