Function identity of non-configurable accessors

Brandon Benvie brandon at brandonbenvie.com
Sat Dec 15 13:26:34 PST 2012


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 <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
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121215/d6bcefeb/attachment-0001.html>


More information about the es-discuss mailing list