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.
/be _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
