__proto__ security

Gavin Barraclough barraclough at apple.com
Sat Jan 28 14:21:00 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.

If the spec includes an optional normative definition of __proto__ that requires it to be a configurable property of Object.prototype then a significant rewrite of JSC's __proto__ implementation will be necessary.  That's okay – it seems worthwhile doing so to make it possible to delete the __proto__ property.  The logical way to implement this in JSC is likely as an accessor property.

So the question for us is not whether changing our implementation is necessary (it is), but rather whether having cleaned this up, we will then need to add back in new magic to make __proto__ masquerade as a data descriptor to match SpiderMonkey.  The less magical __proto__ is the better, so this seems undesirable.  Since the implementation in JSC will need to change anyway, we're motivated to aim for the least magical behaviour, but for SpiderMonkey, which already has a better implementation for __proto__, I can see why requiring a change would be undesirable.

On Jan 28, 2012, at 10:20 AM, David Bruant wrote:
> 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__.

Given this is __proto__ we're talking about, maybe it just isn't worth being overly specific here?

How about we just specify that:
	* The only permissible way to modify an object's [[Prototype]] is through __proto__. 
	* __proto__ must be a property of Object.prototype.
	* __proto__ must be configurable.

This would mean that any conforming implementation would have a easy, spec-defined way to remove __proto__, without burdening browsers who implement this as a data descriptor to change their implementations to make it an accessor descriptor, or burdening browsers who implement this as an accessor descriptor to change their implementations to make it a data descriptor.

Are there a significant practical benefit of a more restrictive specification that this fails to cover?


More information about the es-discuss mailing list