Re: __proto__ security

On Feb 10, 2012, at 2:29 PM, Brendan Eich wrote:

> Allen Wirfs-Brock wrote:
>> On Feb 10, 2012, at 11:24 AM, Brendan Eich wrote:
>> 
>>> Hi Tom, this may repeat parts of replies from others, if so please bear with me:
>>> 
>>> I think __proto__ should be a bit magical, and in particular should not be proxy-able. Annex B is
becoming "Normative Optional", meaning you are not required to implement its contents to conform to
ECMA-262, but if you do support the specified APIs, then Annex B's spec is normative.
>> 
>> A different approach is to tie the semantics to language syntax instead of making it part of the "virtual
machine" that is defined by the internal methods.  For example, I could specify the [[Prototype]]
mutating behavior of an assignment to the __proto__ property as an extension to the evaluation semantics
of the simple assignment operator (11.13.1).  An advantage to doing it this way is that it can only be
trigger by using that specific syntactic form.  In particular, other syntactic constructs that in do
[[Put]]'s and all the [[Put]]'s in built-in and host functions would not trigger it.
> 
> Some engines do use syntactic specialization, in particular I recall Rhino doing that. But do web-facing
engines that support __proto__ do that? What do they do with o['__proto'+'__'] and the like? Anyone know?

The only rules we have in JSC wrt syntactic identification of __proto__ are to prevent people from naming
functions __proto__ :D

> 
> 
>> The approach I took in my proposal for the handling of __proto__ in object literals is another example of
this syntactic approach.
> 
> That case needs special handling, and the syntax can be specialized there without loss of generality.

Indeed, if we switched to any value on the Object prototype for __proto__ we'd need to special case it in JSC
(presumably spider monkey already does) actually JSC already specialises, purely to allow __proto__ to
work in literals :D
--Oliver