Another de-facto insecurity we need to fix in ES5

Mark S. Miller erights at
Wed Jun 17 19:34:57 PDT 2009

On Wed, Jun 17, 2009 at 7:10 PM, Maciej Stachowiak <mjs at> 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.


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es5-discuss mailing list