The malicious script could schedule patching newly loaded code directly without even overwriting Object.prototype (eg. to reuse your example, it could replace document.location.href occurences with a string constant in the 'trustworthy' function source directly).
Not if the code in question is inside a self-executing function closure, which is a pretty common pattern. In that case, the only "vulnerability" to trusting what you see from `Object.prototype.toString` (or `location.href.toString`) is if it's possible that someone paved over them earlier, either intentionally or accidentally.
This means forbidding overwriting properties of Object.prototype would be 'security by obscurity' at best imho.
I already acknowledged that it's only one tiny piece of the overall "code security" discussion... but it would certainly help a few of those use-cases to be more secure.
Maybe the more appropriate term instead of "secure" is "reliable". For example, the case of testing for the validity of `window.opera`... that special object could be more trusted/reliable (not faked or accidentally collided with) if it was impossible to fake the output of `Object.prototype.toString.call(window.opera)`.
On 1:44 PM, Douglas Crockford wrote: I agree that the primordials should have been frozen, but as Brendan says, that ship has sunk. But a smart library can now do that job, so a page can elect to have the benefit of frozen primordials if it wishes.
Again, a "smart library" can only do that if it's guaranteed to be the first code to run on the page. If not (which is usually the case), then all bets are off, unless the language offers some protections.
And "ships being sunk" not withstanding, I think it's a valid question if something like this could be a future candidate for a more "strict" (opt-in) JavaScript, like Harmony/Harmony.Next or "strict mode" itself.
--Kyle _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
