__proto__ security

David Bruant bruant.d at gmail.com
Sat Jan 28 10:20:08 PST 2012

Le 28/01/2012 18:16, Brendan Eich a écrit :
> I don't think we should change __proto__ unnecessarily from current
> implementations, including making it an accessor. Neither JSC nor
> SpiderMonkey does that.
> We do need the ability to delete it, so it should live on
> Object.prototype and be configurable.
Having given more thought about it, I agree that making __proto__ a
setter is unnecessary and will lead to some additional complication.
Benefits are things that are not wanted anyway.

It is unnecessary, because it is currently not a setter everywhere (so
if people rely on __proto__, they do not rely in it being an accessor)
and if __proto__ was an accessor it would be an encouragement to use the
setting part as a capability.
If a setter could be extracted, people will write code extracting it and
lead to a position from which implementors won't be able to come back,
maybe permanently being stuck with a [[Prototype]] setting capability in

Regarding the specification (as optional normative) of __proto__ as an
data descriptor, either the spec can invoke some magic (which is what
implementations already do from an ES5 point of view) or redefine
Object.prototype as a proxy. The target of this proxy would be the
standard Object.prototype and the handler would just define some trap
behavior that deal with __proto__.


More information about the es-discuss mailing list