Is there any leak if you set the accessor functions to have a null [[Prototype]] and to have no non-primitive properties?
On Sat, Dec 15, 2012 at 4:20 PM, Brendan Eich <bren...@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@mozilla.org > https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
