__proto__ security
Allen Wirfs-Brock
allen at wirfs-brock.com
Fri Feb 10 14:58:58 PST 2012
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
More information about the es-discuss
mailing list