__proto__ security

Mark S. Miller erights at google.com
Sat Jan 28 20:50:33 PST 2012

On Sat, Jan 28, 2012 at 12:16 PM, Brendan Eich <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*

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.

I like your proposal because I think the intra-frame protection it provides
is nice. But I don't think it is essential. If __proto__ does reflect as an
accessor as currently stated in the strawman, with the inter-frame
restriction, I think that would be ok.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120128/390f291d/attachment-0001.html>

More information about the es-discuss mailing list