Mark S. Miller wrote:
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 <[email protected]
<mailto:[email protected]>> 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.
Is this something the market can fix? Browsers with __proto__ will be unsafe for
mashups. Sites that care about their users' safety will recommend sans __proto__
browsers. Parents who care about the safety of their families will install only
sans __proto__ browsers. The share of the dangerous browsers falls to nothing
and the safer browsers prevail. Problem solved.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
