Mutable Proto

François REMY francois.remy.dev at outlook.com
Thu Mar 21 02:38:10 PDT 2013


> 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. 		 	   		  


More information about the es-discuss mailing list