Douglas Crockford wrote: > 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. 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. > > 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.
It is true that you brought this up on the first day you came to the meetings. I said then, and I say again now, that I think we will actually be putting ES4 programmers in a better position wrt. safety than ES3 programmers. I wonder if the following two basic facts about the ES4 environment are clear. I've brought them up in the past but you usually dismiss them rather than saying why exactly they don't help: - fixtures in ES4 are early-bindable, non-overridable and (in cases of methods, types, classes, and other sorts of constants) non-replaceable. Intercepting control from a script that uses fixture names by mutating some part of the global object or prototypes is *not possible* in this design. - 'use namespace intrinsic' at the top of an ES3 file, then publishing it under the ES4 mime type, should be enough to accomplish this in many cases. All the multiname references that would previously hit the prototype chains and/or global.foo bindings become fixture references that XSS code cannot intercept. Even if they don't early-bind due to the absence of type annotations on slots, the multinames wait around until runtime and the fixtures *mask* the public names / prototype chains. Do they not help with some of the XSS scenarios? I imagine that they would, but have not nearly the depth of experience with XSS problems. -Graydon _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
