Another de-facto insecurity we need to fix in ES5
mjs at apple.com
Wed Jun 17 19:10:16 PDT 2009
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.
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
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. Maybe in the next version.
More information about the es5-discuss