> If against all odds, all code everywhere *did* magically drop __proto__
> in favor of Object.setPrototypeOf, then 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__.
Well, I don't completely agree with you on this. It would be easy to protect
objects using
Object.freezePrototype(o)
or
Object.definePrototypeSetter(o, function(o,p) {
if(isValid(p)) return p else throw new Error('...');
}).
I would really like to know how you expect SES to secure a property that lays
in the Object.prototype object and could be overriden by a malicious object to
intercept your __proto__ setter calls.
BTW, you could also *redefine* Object.setPrototypeOf to match your security
requirements without completely removing it.
I know it's not your point of view, but if MSFT never implements __proto__ in
IE (except behind a 'compatibility' mode for sites that rely on it, in the
Opera's browser.js way) and if everbody do implement Object.setPrototypeOf(...)
then the few libraries using __proto__ will end up migrating to
Object.setPrototypeOf(...) or use a polyfill for __proto__ in the case it isn't
supported.
Phasing out failed experiments *is* possible. I don't think a browser that
doesn't support <blink> or <marquee> or even document.layers would have a lot
of problems to view the web as it's now, yet I remember a time where
document.layers <marquee> were used quite a lot. I do think the argument used
to claim __proto__ is unfixable is somewhat wrong.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
