ES1-3 eval-created function bindings can be used to destroy caller bindings

Brendan Eich 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  
spans. ;-)

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).

/be


More information about the Es-discuss mailing list