ES1-3 eval-created function bindings can be used to destroy caller bindings
brendan at mozilla.com
Fri Feb 13 11:06:13 PST 2009
On Feb 13, 2009, at 9:44 AM, Allen Wirfs-Brock wrote:
> I'm not yet convinced that this really is a significant ES3 to ES3.1
> compatibility issues.
Not sure either, why I wrote "I can't prove this is going to burn
programmers in the future, but I suspect it will."
> I don't see that the specified behavior would be a problem for new
> code, written specifically to use ES 3.1 features including accessor
> properties and attribute manipulation. I believe that the current
> ES3.1 draft is complete and consistent in what will happen when
> those features are used in conjunction binding instantiation in
> Object Environment Records. New code that uses 3.1 features should
> expect to get 3.1 semantics.
That may not help if we make it unnecessarily hard to compose old and
new code in the global object. It's an issue for existing code, and if
you expect new code to use Object.getOwnPropertyDescriptor before
declaring a function, just in case there's an accessor of the same
name, I will bet you no one will write such code in the future, even
if you staple ES3.1's spec to their foreheads.
> I do think that I could probably fix the concern with some rewriting
> of 10.6 (Binding Instantiation) and the Environment Record interface/
> implementation to ensure that functions get a "fresh" property in
> the binding objects. However, I'm reluctant to mess with already
> "debugged code", ie the specification, at this point unless this is
> more than a hypothetical problem.
That's fine. I'm not asking for a change, just discussion. We should
implement and test.
> Can anybody identify any real scenarios based upon existing
> implementations and existing code where this change in semantics is
> actually going to cause a forward compatibility problem?
Hate to say it, but you buried the important part too, for anyone not
digging below the fold. But this topic isn't for short attention
Laying a trap with __defineSetter__ and __defineGetter__ on the global
object, to take over a function (wrap it to spy on its params), would
have to depend on a failure to judge trustworthiness. But this happens
(perl.com's ad supplier let its domain lapse, and pr0n.com grabbed it
and hijacked location). The ES1-3 function declaration super-power of
blowing away any pre-existing property provided some protection, but
really, if the enemy is within the gates, you're dead.
So the more plausible threat, and a lesser one, is defending in a non-
hostile case against other code that was loaded previously. Even
native global bindings might be configurable and writable, for
backward compatibility (undefined comes to mind, along with many DOM
level 0 additions over the years). If these are all data properties,
no problem. If any is an accessor, then it's hostile to existing or
future code that wants to name a function with the same identifier.
Thanks for the reply, it helps to talk this stuff through (I don't
have as much time to think about it as I'd like).
More information about the Es-discuss