Fwd: B.3.1 The __proto__ pseudo property
Mark S. Miller
erights at google.com
Tue May 7 09:01:09 PDT 2013
Earlier private correspondence with Allen about a line of reasoning I
promised to write up and post to es-discuss. I still haven't found the time
to write this up, so simply posting this correspondence in the meantime.
[with a slight bit of editing]
---------- Forwarded message ----------
From: Mark S. Miller <erights at google.com>
Date: Sun, Apr 28, 2013 at 10:52 AM
Subject: Re: B.3.1 The __proto__ pseudo property
To: Allen Wirfs-Brock <allen at wirfs-brock.com>
On Sun, Apr 28, 2013 at 10:41 AM, Allen Wirfs-Brock
<allen at wirfs-brock.com>wrote:
> Do you think we can come to some sort of agreement, as discussed below,
> that [[ProtoSetter]] doesn't need to be realm restricted. Such an
> agreement would let us write the simplest possible specification of
Very timely question. I've discussed this within the other Cajadores and
the answer is yes. While the range restriction help security in some ways,
it doesn't help a lot, and it actually hurts in other ways. Such simplicity
itself is of benefit to security, and weighs in the overall tradeoff. On
balance we're better off without it. I'll be posting publicly on this soon.
> It would eliminated having to introduce general object/realm
> associations into the spec. including whatever unanticipated complications
> come with them.
We will still need this in ES7 to support weak references, but it is good
we can postpone till ES7.
> It would also remove all obstacles to having Object.setPrototypeOf which
> a number of vocal community members would really prefer to have built-in
> and available rather than having to use __proto__ ugliness.
Yes. All objections to this disappear. And likewise for having proxies
handle trapping proto changes differently from their handling of other
> I'd really like to get resolution on this so we can get it out of the way
> once and for all and concentrate on higher leverage spec. work.
> What do you think?
Happiness all around !
> (PS, If you don't think [[PreventExtensions]] gives SES fine-graned enough
> control on [[ProtoSetter]] then I'd vastly perfer having a per object
> [[PreventProtoTampering]] over some sort of realm-based control.)
That would help some. But the pressure for it from our new understanding of
the security implications isn't high, and so probably not high enough to
cause it to happen. I'm fine without this extra bit.
> On Apr 23, 2013, at 5:52 PM, Allen Wirfs-Brock wrote:
> On Apr 23, 2013, at 5:10 PM, Mark S. Miller wrote:
>> Regardless, what is so special about the [[ProtoSetter]] operation that
>> it needs to be restricted in this way? It's just a capability and you know
>> how to control access to capabilities. You also know how to protect
>> objects from having their [[Prototype]] mutated. If I have any object,
>> that inherits from a different realm's Object.prototype I can navigate to
>> its constructor property which gives me access to that other realm's,
>> Object.create, Object[[@@create], and all the other Object.* functions.
>> Why isn't being able to find and apply some other realms Object.free[ze]
>> just as scary as finding its [[ProtoSetter]]?
> SES includes Object.freeze in its set of universally available
> primordials. Thus, an Object.freeze from a foreign non-SES-secured realm is
> not a threat since Object.freeze is already universally available to
> confined ("untrusted") code within the local SES-secured realm.
> I expect SES initialization will delete Object.prototype.__proto__ or at
> least remove its setter. It is conceivable SES will hold the setter off on
> the side for some special use. But regardless, it will probably[*] deny
> these powers to confined code within that SES-secured realm. Thus, SES
> code, including confined code, should be able to safely assume that the
> [[Prototype]] of its own objects won't be mutated.
> When SES code interacts only with SES code, whether intra or inter realm,
> then this is the end of the story and the cross realm threat is not an
> issue. But SES objects must be able to maintain their own integrity even
> when exposed to non-SES objects from other frames. That was impossible for
> ES5/3, the Caja translator from ES5 to ES3, since Object.freeze was
> emulated, and thus only enforced for translated code. As of ES5,
> Object.freeze protects unconditionally (which was why <
> https://bugzilla.mozilla.org/show_bug.cgi?id=674195> gave Caja so much
> So if SES code should generally be able to assume that its own
> [[Prototype]]s are stable, we need to preserve the safety of that
> assumption when objects from a SES-secured realm are exposed to objects
> from a non-SES-secured realm.
> Which you would just do so by make your object's non-extensible, right?
> That does more than just limit setting of [[Prototype]] but it does that
> job too. I've previously proposed we have an independent per object
> immutablePrototype state which would be more targeted, but that didn't find
> any support.
> [*] I say "probably" to hedge my bets. The hard constraint we absolutely
> require is already guaranteed by ES5: That the [[Prototype]] of a
> non-extensible object cannot be mutated. Given that, it is possible (though
> unlikely) that SES will choose to make the setter universally available, in
> which case you are correct and the inter-realm checks I'm insisting on are
> for naught.
> Since you've decided it's ok to make Object.freeze, defineProperty, etc.
> universally available why wouldn't you also make setPrototypeOf (ie,
> [[ProtoSetter]]) universally available and just preventExtensions on object
> you need to protect from that. It it just the general distaste for
> __proto__ that most of us share with you?
> You haven't yet convinced me that there is actually a need for these realm
> restrictions on [[ProtoSetter]] and for something seemingly so arbitrary we
> should really have a strong case for why it is important. The ES world
> would be simpler and cleaner within the restrictions and there would be no
> particular reason for not making Object.setPrototypeOf available as an
> alternative API for those that prefer it.
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss