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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
