B.3.1 The __proto__ pseudo property

David Bruant 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 
[1] 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" 
hereafter)
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.

David

[1] 
http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#navigate


More information about the es-discuss mailing list