Object.prototype.* writable?

[Kyle Simpson]

> 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