__proto__ security

[Allen Wirfs-Brock]

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

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

I worried about this a bit when I first thought about this approach.  However, it really doesn't matter if the behavior  is tied to the semantics of the basic assignment operator.   That operator gets a Reference as its RHS value so it doesn't matter if you say obj.__proto__ or obj[__proto__] or obj["__pro"+"to__"].  

> 
>> The existence of a Object.prototype.__proto__ property (perhaps a special one) seems like a plausible way to do this this.  On the other hand, there is also nothing preventing us from simply specify a new global function __proto__disable__ (or any other triggering mechanism we might agree on)that could be called to disable the __proto__ feature.
> 
> We shouldn't go too far afield from today's code. True, SpiderMonkey has O.p.__proto__ non-configurable, but we can and (I think) will change that so it can be deleted. That's the shortest path to a disabling API, no need for __mumble__ APIs.

The main reason I mention the turn-off via a global function alternative, is that it in combination with a syntax linked specification eliminates the need to worry about whether O.p.__proto__  is an accessor or data property or its attribute values. It simply is not a property under that approach.  

Allen