Function identity of non-configurable accessors

David Bruant bruant.d at gmail.com
Sat Dec 15 14:46:00 PST 2012


Le 15/12/2012 22:26, Brandon Benvie a écrit :
> Is there any leak if you set the accessor functions to have a null 
> [[Prototype]] and to have no non-primitive properties?
There isn't. That would be the super-minimal "null realm" solution.

David

>
>
> On Sat, Dec 15, 2012 at 4:20 PM, Brendan Eich <brendan at mozilla.com 
> <mailto:brendan at mozilla.com>> wrote:
>
>     David Bruant wrote:
>
>         Le 15/12/2012 19:11, Brendan Eich a écrit :
>
>             David Bruant wrote:
>
>                     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.
>
>
>             Frozen accessors would be best if we can get away with the
>             incompatibility.
>
>         I've given more thought. Frozen accessors can't be a solution.
>         Only deeply frozen would be.
>
>
>     Oh sure -- that goes without saying (or so I thought when I wrote
>     it :-P).
>
>
>         If the accessor isn't deeply frozen, then, it means that any
>         non-frozen object that can be reached through the accessor can
>         be used as a communication channel between 2 browsing contexts
>         that were in the same iframe.
>         Among other things, "deeply frozen" means to freeze the
>         accessor's [[Prototype]] which is Function.prototype which is
>         probably not workable.
>
>
>     Yes, so to avoid the "Ice-9" problem, these would have to bottom
>     out in a "null realm" where everything is frozen:
>     Function.prototype, Object.prototype, anything else required (is
>     anything else required for function objects to be deeply frozen?).
>
>
>         Or there are probably other things like comparing iframes
>         contentWindow.Function.prototype objects over time (when
>         changing src) that wouldn't be compatible.
>
>
>     If you buy the "null realm" idea, the only breaking change would
>     be if someone could extract the get or set function via
>     __lookupGetter__/__lookupSetter__ or the ES5 standard forms,
>     inspect them and find the current window's realm built-ins. Or
>     monkey-patch the current realm's built-in Function.prototype or
>     Object.prototype and expect those properties to be inherited by
>     the get and set functions.
>
>     But this seems like something we could get away with breaking, maybe.
>
>
>         Back to the idea of reflecting different getter/setters for
>         non-configurable accessors, I guess.
>
>
>     Let's talk about deep-freezing and the null realm more.
>
>     /be
>
>     _______________________________________________
>     es-discuss mailing list
>     es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>     https://mail.mozilla.org/listinfo/es-discuss
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121215/54301732/attachment.html>


More information about the es-discuss mailing list