B.3.1 The __proto__ pseudo property
bruant.d at gmail.com
Thu Apr 25 05:05:27 PDT 2013
Le 23/04/2013 17:52, Allen Wirfs-Brock a écrit :
> On Apr 23, 2013, at 5:10 PM, Mark S. Miller wrote:
>> [*] 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.
This certainly begs for a longer and more educated answer than I can
provide, but I believe one issue is that as far as web browsers are
concerned, new realms can be created dynamically
(document.createElement('iframe')). So if you have a piece of code in
which assume [[ProtoSetter]] is generally not available (because you
delete-d it or kept it for you), then this assumption can be broken by
creating a new realm, extracting its [[ProtoSetter]] and using it in
ways you didn't expect.
Now, this all relies on the ability for a partially trusted third party
to create a new realm. If it is assumed that any code and create new
realms without restrictions, then, a realm check in [[ProtoSetter]] is
necessary. However, if the ability to create new realms is kept under
control, then the realm check in [[ProtoSetter]] should not be necessary.
For the browser, it may be possible to confine code, list all
capabilities that creates new realms and prohibit access to the
[[ProtoSetter]] of any new confined realms. I think it should be
possible, but same-origin iframes are a headeache. Basically,
document.createElement('iframe').contentWindow does not give access to
one new realm. A new realm is created anytime the iframe is navigated
 to a new resource (iframe.src is set to a new value or whatever
inside the iframe caused it to be navigated, etc.). In that case, is it
possible always possible for the confiner to access the new realm
[[ProtoSetter]] before anyone else? ("iframe confinement question"
I don't have the answer to this question.
I'm particularly worried of scenarii where an iframe would open, run
some code unconfined and can "hide" [[ProtoSetter]] somewhere and pass
the capability to supposedly confined code later down the road. Here,
the important question is: can same-origin iframe code run unconfined?
If the answer to the "iframe confinement question" is yes, then new
realms can be confined and [[ProtoSetter]] is under control and the
[[ProtoSetter]] realm check isn't necessary. If the answer is no, then
the [[ProtoSetter]] realm check is necessary.
More information about the es-discuss