On Wed, Jun 17, 2009 at 7:10 PM, Maciej Stachowiak <m...@apple.com> wrote:
> > On Jun 17, 2009, at 3:34 PM, Mark S. Miller wrote: > > >> I suspect we'll see some de-facto stuff come out of one or two vendors who >> aren't active in TC39 (Apple, Google V8). >> >> >> Google is quite active in TC39. Google's representatives to TC39 >> (including me) are now in close coordination with our v8 team. However, v8 >> remains committed to following WebKit. Fortunately, AFAIK, WebKit has not >> yet taken any stance on whether [[Prototype]] will be mutable in their ES5 >> implementation. Maciej? >> > > Your phrasing of the question strikes me as odd, because changing behavior > of de facto extensions like this seems orthogonal to supporting a new > version of the spec. If getting rid of or restricting mutable __proto__ > turns out to be feasible and a good idea, then we would not tie it to > implementation timeline for ES5 features. > The tie to ES5 is that ES5 introduces the notion of frozen objects. Together with ES5/Strict function's encapsulation being protected even from non-strict code, this enables the creation of tamper-proof objects. But only if frozen objects cannot have their [[Prototype]] property changed out from under them. > > As to the substantive issue: mutable __proto__ is something we would prefer > not to have, but we are concerned about the compatibility issues. We look > forward to hearing about Mozilla's experience with changing it. > In case this experiment does run into problems, what do you think about Allen's proposed restriction: "That [[Prototype]] is guaranteed not to change on an object for which [[Extensible]] is false."? This takes care of the security issue I'm concerned about and won't break any old code. > > Personally, I think leaving "distasteful" but cross-browser features like > this out of the spec in the hopes that they will wither away from neglect is > a poor approach. If browsers feel pressured to implement such extensions for > Web compatibility then we are not doing anyone any favors by leaving them in > the domain of mutual reverse-engineering. I would prefer to see such > features explicitly specified (with suitable restrictions) or explicitly > forbidden, and perhaps explicitly deprecate them with the plan for further > limits or outright removal in future versions of the spec. But it seems too > late to make big changes in this regard for ES5. Agreed. > Maybe in the next version. > +100. An exhaustive list of such features should at least be enumerated in a non-normative appendix. If they had, it wouldn't have taken us so long to catch the mutable [[Prototype]] and F.caller issues. What other such issues might we have missed? In a closely related matter, we also need to tighten the Chapter 16 exemptions, as the presence of these exemptions precludes *any* sound reasoning about JavaScript security. However, I have no clever ideas of what such tighter language should say. Suggestions appreciated. -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
