Es4-discuss Digest, Vol 8, Issue 44

[Brendan Eich]

On Oct 30, 2007, at 5:03 PM, Douglas Crockford wrote:

>> Brenden is also correct:  If the working group voted and
>> the current
>> proposal won - it is better to have a stronger, more secure
>> language.
>> Sure they can argue it is bloated, but SO WHAT?
>
> The proposal is not a more secure language. It does nothing to  
> address ECMAScript's biggest  design flaw: the insecurity caused  
> its dependence on a global object.

Yes, ES4 is backward-compatible, so it still has a mutable global  
object. Mutable prototypes are a hazard too, but required by backward  
compatibility.

Breaking the global object's mutability without opt-in from new code  
would break the web, so I'm surprised you are complaining about it.  
We've seen each other in TG1 meetings since July 2006, but no one  
including you has come up with a proposal to solve this problem  
compatibly, except by doing exactly what we have done: adding  
features in ES4 that developers can use to control visibility and  
mutation. The very features you oppose.

ES4 provides const, fixed typename bindings, lexical scope (let),  
program units, and optional static type checking -- all of which *do*  
make ES4 code easier to analyze and instrument to enforce security  
properties.

> XSS attacks are a direct consequence of this flaw. By making the  
> language more complex, this problem becomes even harder to reason  
> about and fix.

No, ES4 with const, fixed typename bindings, lexical scope, program  
units, etc. is easier to reason about  than ES3, not harder.

ES4 is easier to reason about automatically. It's ironic that you  
invoke reason. Reasoning about code should not be done by humans  
only. Reason => logic => proof => proof system <=> type system, as I  
wrote at ajaxian.com in a comment recently.

Your own words invoke the Curry-Howard correspondence, which requires  
a type system that supports static analysis, as well as unambiguous  
name binding. ES4 directly supports type checking and unambiguous  
name binding. Yet you seem to oppose all of ES4, especially the type  
system. That seems contradictory.

> I have been bringing this up since my first day in the working  
> group. This is not a concern that is being sprung at the last minute.

I remember the 2006 July meeting well, and the minutes are posted here:

http://wiki.ecmascript.org/doku.php?id=meetings:minutes_jul_27_2006

I don't think you suggested anything not recorded in some way there.  
If you mean that the item under "Yahoo!s position" about security  
promises motivating Yahoo! to entertain a new and incompatible  
language, that claim led nowhere. Mainly because unlike Yahoo!,  
browser vendors and web developers in general will not tolerate  
incompatibilities for "Security" -- but also (more important) because  
no one has a convincing solution for capital-S Security, other than  
adding features to ES3 that users can choose to control mutability  
and more conveniently and efficiently hide names.

The eval discussion recorded in those minutes did lead to a decision  
by the group not to support a sandbox optional argument to eval. It  
also apparently led to that es3.1 String.prototype.eval idea, which  
you have not proposed for ES4. Too bad, but perhaps we'll be able to  
include it in anyway.

> The working group hasn't voted. The proposal has not won. We have  
> agreed to disagree, developing two competing proposals in the same  
> working group. I am pursuing with Microsoft a counter proposal for  
> a simpler, reliable remedy to real problems. My position isn't that  
> JavaScript doesn't need fixing. I think we need to be more  
> selective in how we fix it. Bloat, in my view, is not good design.

Who could argue with that?

Since backward compatibility matters a lot to us, both to conserve  
working code so some of it can be gradually migrated to ES4, and to  
minimize code footprint for a common ES3/ES4 implementation on small  
devices (you've heard both of these points since the July 2006  
meeting), we have indeed made some additive changes -- 'let' in  
addition to 'var', for example. We've even prototyped some of these  
in Firefox, to prove they didn't break anything (with opt-in  
keywords) and did not exact a big code footprint cost (they did not).

This approach shows serious concern for compatibility, but in spite  
of it, we still get "break the web" FUD. Yet our "compatibility  
through opt-in additions" approach also makes it all too easy for  
someone arguing casually to accuse ES4 of being bloated. Catch-22.

Taking the high road here does nothing but pat yourself on the back,  
and for work not visible to anyone except you and Microsoft (and some  
Ajax developers who got advance copies? That "ES4 will break the web"  
covert blog-spin campaign leaked, BTW). What good does it do to  
posture against bloat when your alternative proposal is hidden? I'm  
assuming there is an alternative proposal beyond some JScript documents.

Look, I can take a different high road and mimic your arguing style:

"Everyone familiar with the uses of closures in JS (for information  
hiding), something you've championed, who has run into closure- 
induced leaks and the larger object population costs of too many  
closures, will say your proposal is the opposite of bloated: stunted,  
insufficient, inefficient."

Doesn't feel very good to be on the receiving end, does it? I didn't  
have to do any work to demonstrate my claims. I didn't even have to  
state problems precisely.

It would be great if you could start, after over a year of  
involvement in TG1, and a while in es4-discuss, to communicate  
better. I'm glad to have as many words as you've sent today, even  
with the bloat remark, given how few specific and actionable words  
you've uttered to TG1. But the bloat accusations and superior- 
sounding claims to be selective need to stop. Everyone working on TG1  
has been selective by some criteria. No one wants bloat. For us to  
get anywhere and avoid a fork, this kind of rhetoric has to stop.

/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20071030/d19b94c8/attachment-0002.html