Another de-facto insecurity we need to fix in ES5
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__.
More information about the es5-discuss