A Precedent

Brendan Eich brendan at mozilla.com
Fri Apr 12 16:05:39 PDT 2013

Andrea Giammarchi wrote:
> >  Adding Object.setPrototypeOf does not help, because code won't migrate to it
> >  completely so we'll be stuck with two APIs.
> As shown in the first post we'll be stuck with 4 APIs plus the 5th one standardized.

What 4 APIs are you talking about?

> The __proto__ that is not supported, the one that is wrongly inherited in Object.create(null), the non configurable, and the configurable without get/set

The old ones go away. We can't fix browsers in the field, you know that. 
Your argument is unfairly lumping changes we *can* make with ones we 
can't and counting them all against the ones we can make.

> >  SES and similar subsets would be
> >  unable to protect secure code from ambient Object.setPrototypeOf usage
> >  from the insecure side on the secure side's objects, unless
> >  Object.setPrototypeOf were removed -- but that would break insecure-side
> >  code that reasonably (per your wishes) uses Object.setPrototypeOf in
> >  lieu of __proto__.
> same way SES can protect from __proto__ it can protect from Object.setPrototypeOf redefining in a way that who's white listed can obtain same result.

No, same-frame mashups of SES and 
non-SES-that-uses-Object.setPrototypeOf cannot "whitelist" unless every 
SES object (or alternatively non-SES object) is put in a whitelist weak-set.


More information about the es-discuss mailing list