__proto__ security

Brendan Eich brendan at mozilla.org
Sat Jan 28 23:30:15 PST 2012

Mark S. Miller wrote:
> On Sat, Jan 28, 2012 at 12:16 PM, Brendan Eich <brendan at mozilla.org 
> <mailto:brendan at mozilla.org>> wrote:
>     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.
>     Ignoring the "don't gild the lily" (or "don't polish the turd")
>     advice above, if we *do* reflect __proto__ as an accessor, then
>     the same-frame problem still exists. Perhaps it can be solved by
>     proxies, but why require that?
> I didn't follow that. The current strawman 
> <http://wiki.ecmascript.org/doku.php?id=strawman:magic_proto_property> 
> says in step 2 of [[ProtoSetter]]:
>     2. If O is not an object from this context, throw a 
> *TypeError* exception.
> I don't say anything about how this test is performed because we don't 
> yet know how we'll represent the extra bookkeeping needed to spec the 
> interaction of multiple globals. This is inter-frame protection only.

Yes, that's why I wrote "the same-frame problem still exists".

> I like your proposal because I think the intra-frame protection it 
> provides is nice. But I don't think it is essential.

It's hard to prove what is essential, but my "proxies" point was to ask: 
must membranes be used to protect here, when the pseudo-data-property 
approach relieves us of any such requirement?

> If __proto__ does reflect as an accessor as currently stated in the 
> strawman, with the inter-frame restriction, I think that would be ok.

It's ok but I think the pseudo-data way is "more ok" ;-).


More information about the es-discuss mailing list