Another de-facto insecurity we need to fix in ES5

David-Sarah Hopwood david-sarah at jacaranda.org
Tue Jun 23 13:04:58 PDT 2009


Allen Wirfs-Brock wrote:
>> -----Original Message-----
>> From: es5-discuss-bounces at mozilla.org [mailto:es5-discuss-
>> bounces at mozilla.org] On Behalf Of David-Sarah Hopwood
>>
>> The existing draft already precludes any modification of __proto__ after
>> Object.freeze. That's because __proto__ is an own property. 
> 
> In whose implementation?  How do you know that somebody's hasn't implemented
> __proto__ as a getter property that is inherited from Object.prototype?

It wouldn't matter. If own properties and internal properties were both
immutable after Object.freeze, then there would be no state directly
associated with the object that a getter could access.

Of course it is possible that an implementation could indirectly associate
state with an object via some global table. But that would be a bizarre
thing to do that would clearly be contrary to the spirit of the restriction,
if it were observable.

>> The oversight is that internal properties are not own properties (I think).
> 
> "internal properties" are neither own nor inherited properties.

So as I said, they're not own properties. Therefore they are not frozen
by Object.freeze. This does not correspond to the intent of the spec, which
is that an object be made shallowly immutable, as far as is observable,
by Object.freeze. This intent is not directly stated, and it should be.

In any case, I repeat that there is no reason to distinguish between
[[Prototype]] and other internal properties in this respect.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com




More information about the es5-discuss mailing list