Another de-facto insecurity we need to fix in ES5

Alex Russell alex at
Wed Jun 17 21:08:43 PDT 2009

Hash: SHA1

On Jun 17, 2009, at 7:34 PM, Mark S. Miller wrote:

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

The fact that ES5 has the provision for frozen objects doesn't mean  
that all (or substantially most) objects in the system will be frozen.  
I think it's worth considering how useful killing __proto__ will be  
should the Harmony class system NOT freeze objects by default. I  
suspect not very.


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

- --
Alex Russell
slightlyoff at
alex at BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723

Version: GnuPG v1.4.2 (Darwin)


More information about the es-discuss mailing list