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