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

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