Function identity of non-configurable accessors

David Bruant bruant.d at
Sat Dec 15 07:14:00 PST 2012

Le 15/12/2012 15:49, Sam Tobin-Hochstadt a écrit :
> On Sat, Dec 15, 2012 at 9:27 AM, David Bruant <bruant.d at> 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 at 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 

> 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 

>> 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.


More information about the es-discuss mailing list