Re: Another de-facto insecurity we need to fix in ES5

> As I just mentioned on the debugging API thread, at the last EcmaScript
> meeting we agreed
>
> On Mon, Jun 1, 2009 at 5:11 PM, Waldemar Horwat <waldemar@...
> <mailto:waldemar@...>> wrote:
>
>     Rather than describing the evil things that implementations do with
>     F.caller, we agreed to just impose a blanket prohibition of code
>     peeking into the environment records or identity of strict functions
>     on the stack.  This way a test suite can ensure that F.caller does
>     nnot reveal strict functions without us having to introduce the evil
>     things into the standard.  I'll write up proposed wording.
>
>
> This is an example of a more general principle. The language we're
> evolving from isn't ES3, it's ES3 as currently practiced. When browser
> vendors implement ES5, they won't actually implement ES5 as speced. They
> will implement ES5 as extended to preserve some of the defacto practices
> they currently support. When these likely future defacto extensions
> would lose some of the integrity or security gains we're trying to
> achieve with ES5, then we should find an adjustment to the ES5 spec that
> does not break these defacto practices for old code but still allows new
> code to defend itself from attackers using these defacto extensions.
>
> The ES3 and ES5 specs both specify the implicit [[Prototype]] property
> as something that is initialized once and then unchanged. All major
> browsers today but IE alias this to the name "__proto__" (as if that's a
> named property) and allow it to be mutated. None of the rest of the ES5
> semantics has been critically examined in light of the possibility that
> an implementation may allow this mutation. So long as [[Prototype]] is
> pervasively mutable, then most interesting behavior of an ES5 object
> won't be stable as well. I recommend:
>
> Object.freeze(foo) guarantees not only that all of foo's named
> properties be frozen and that foo is non-extensible, but also that foo's
> [[Prototype]] will not be changed.
>
> For non-frozen objects, we continue not to specify that [[Prototype]]
> can be mutated or explain any means for mutating it. But neither can we
> prohibit such mutations unless FF, Safari, and Opera are willing to give
> up this feature. The proposal above won't break any old code that
> depends on mutating __proto__ but will enable new code to protect
> itself. I would like to propose something stronger, but don't know of
> anything stronger compatible with this constraint.