Function identity of non-configurable accessors

Sam Tobin-Hochstadt samth at
Sat Dec 15 06:49:25 PST 2012

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.  That's an implementation issue that browsers will have to
face, not something that needs to be fixed on the 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.  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.


More information about the es-discuss mailing list