this, and the fact descriptors suffer inheritance which for 3 boolean properties or a method are absolutely not helpful and make the env doomed by `Object.prototype.writable = true` shenanigans.
Yes, I'd personally +1 all these fixes that made these ES5 features not the easiest one to play with On Thu, Feb 19, 2015 at 5:41 PM, Mark S. Miller <[email protected]> wrote: > On Thu, Feb 19, 2015 at 9:23 AM, David Bruant <[email protected]> wrote: > >> Hi, >> >> Half a million times the following meta-exchange happened on es-discuss: >> - if an attacker modifies Object.prototype, then you're doomed in all >> sorts of ways >> - Don't let anyone modify it. Just do Object.freeze(Object.prototype)! >> >> I've done it on client-side projects with reasonable success. I've just >> tried on a Node project and lots of dependencies started throwing errors. >> (I imagine the difference is that in Node, it's easy to create projects >> with a big tree of dependencies which I haven't done too much on the client >> side). >> >> I tracked down a few of these errors and they all seem to relate to the >> override mistake [1]. >> * In jsdom [2], trying to add a "constructor" property to an object fails >> because Object.prototype.constructor is configurable: false, writable: false >> * in tough-cookie [3] (which is a dependency of the popular 'request' >> module), trying to set Cookie.prototype.toString fails because >> Object.prototype.toString is configurable: false, writable: false >> >> Arguably, they could use Object.defineProperty, but they won't because >> it's less natural and it'd be absurd to try to fix npm. The >> Cookie.prototype.toString case is interesting. Of all the methods being >> added, only toString causes a problem. Using Object.defineProperty for this >> one would be an awkward inconsistency. >> >> >> So, we're in a state where no module needs to modify Object.prototype, >> but I cannot freeze it because the override mistake makes throw any script >> that tries to set a toString property to an object. >> Because of the override mistake, either I have to let Object.prototype >> mutable (depite no module needing it to be mutable) or freeze it first hand >> and not use popular modules like jsdom or request. >> >> It's obviously possible to replace all built-in props by accessors [4], >> of course, but this is a bit ridiculous. >> > > It is indeed ridiculous. Not fixing this in the ES5 timeframe was my > single biggest failure and disappointment as a member of TC39. > > For reference, Caja's implementation of the technique described in [4] is > at > > > https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/repairES5.js#278 > > As it states, our term for freezing an object so that it does not provoke > this problem is "tamper proofing". > > > >> Can the override mistake be fixed? I imagine no web compat issues would >> occur since this change is about throwing less errors. >> > > There was a time when some of the browsers did not suffer from the > override mistake, and in so doing, were technically out of conformance with > the ES5 spec. During this window, it was clearly still web compatible to > fix the override mistake. It was during this window that I raised the issue > and argued that it be fixed. I brought this up in meetings several times > and never made any progress. Once all browsers suffered equally from the > override mistake, it was no longer *clearly* web compatible to fix it, so I > gave up and focussed on other things instead. > > However, I agree with your suspicion that it actually would still be web > compatible to fix this. Unfortunately, the only way to find out at this > point is for a browser to try deploying without the override mistake. I > don't have much hope. > > Instead, I suggest you promote tamper proofing to those audiences to which > you currently promote freezing. Though the need for it is indeed > ridiculous, it actually works rather well. We've been using it successfully > for many years now. > > > > >> >> David >> >> [1] http://wiki.ecmascript.org/doku.php?id=strawman:fixing_ >> override_mistake >> [2] https://github.com/tmpvar/jsdom/blob/6c5fe5be8cd01e0b4e91fa96d02534 >> 1aff1db291/lib/jsdom/utils.js#L65-L95 >> [3] https://github.com/goinstant/tough-cookie/blob/ >> c66bebadd634f4ff5d8a06519f9e0e4744986ab8/lib/cookie.js#L694 >> [4] https://github.com/rwaldron/tc39-notes/blob/ >> c61f48cea5f2339a1ec65ca89827c8cff170779b/es6/2012-07/july- >> 25.md#fix-override-mistake-aka-the-can-put-check >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> > > > > -- > Cheers, > --MarkM > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
