__proto__ security

Allen Wirfs-Brock allen at wirfs-brock.com
Fri Feb 10 08:29:27 PST 2012

On Feb 10, 2012, at 4:08 AM, Andreas Rossberg wrote:

> On 10 February 2012 12:46, Tom Van Cutsem <tomvc.be at gmail.com> wrote:
>> I'm also in favor of exposing __proto__ as an accessor on the grounds that
>> it is least magical. I'm worried that the changes made here to the core
>> internal methods [[Get]], [[Put]], [[DefineOwnProperty]] and [[Delete]] will
>> give proxies a hard time to properly emulate this behavior if they would
>> want to do that. How would a proxy handler be able to access the internal
>> variable UnderscoreProtoEnabled?
> I also agree that an accessor is much cleaner (if we really want to
> spec this at all -- which will de facto make it a blessed feature
> forever).

I share you concern.

However, we discussed this at the last TC39 meeting.  Because of the current dominance of the smart mobile device space by browsers that support __proto__ browsers that have traditionally not implemented it in the more diverse desktop space are under growing pressure to include __proto__ support if they want to compete in the mobile space.

This is rapidly driving __proto__ towards being a de facto standard.  Part of TC39's mission is to turn de facto standards into de jure standards and in the process provide a uniform definition for the edge cases where current implementation differ.  That is exactly the sort of technical issue that we are now discussing.

> However, I'm not sure the proxy argument applies. Either way, it
> seems, proxies cannot "simulate" the magic of __proto__ themselves,
> because they have no control over the prototype they disclose anyway.
> It can only work for proxies if the magic accessor (whether implicit
> or explicit) transparently forwards the assignment to proxy targets.
> No trap would be involved, just like there is no trap for getting the
> prototype of a proxy.

Proxies could presumably trap the initial  [[Put]]("__proto__") call and from that point do whatever they want.  To change the this objects prototype (without reentering the trap) they would presumably use reflect.set which does a non-trapping invocation of the default [[Put]] internal method. 

> I suppose the real question is: do we _want_ proxies to simulate this
> in full gory glory? That would be blessing this (mis)feature even
> more.

how would we prevent it?

> /Andreas
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

More information about the es-discuss mailing list