Le 15/12/2012 15:49, Sam Tobin-Hochstadt a écrit :
On Sat, Dec 15, 2012 at 9:27 AM, David Bruant <[email protected]> wrote:
The way things are going, WindowProxy [Unforgeable] properties will be
non-configurable getters. If, upon underlying window change, the WindowProxy
is expected to keep the exact same getter function, then, it may result in
capability leaks (attach something in a getter in one iframe and get it back
when the iframe@src has changed).
This is only a capability leak if these getters are, in fact, a
capability.
These getters are objects and can be added properties to, so they could
be used as a communication channel for capabilities across browsing
contexts.
That's an implementation issue that browsers will have to
face, not something that needs to be fixed on the ES side.
Assuming that having different functions for non-configurable accessors
is a requirement for secure WindowProxy and if emulating the DOM
(including WindowProxy) is a use case for ES6 Proxies, then making sure
ES6 Proxies aren't in the way of WIndowProxy requirements is an ES-side
issue.
One solution could be to make these
getters frozen; a better solution would be to not "same getter identity" as
an invariant for proxies reflecting non-configurable accessors.
This sounds like giving up on invariant checking entirely.
Not entirely. The invariant that non-configurable accessor keep being
accessors (and don't change to data property) remains.
If I create a non-configurable property with a getter that I define (such
as `() => 3`), I know that accessing the property will always produce
a known value. Relaxing this restriction means that proxies could
produce whatever they wanted in this situation.
Indeed. Note that it's true currently true with ES5 host objects.
The frozen getter/setter could be a working solution as well.
Davis
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
