__proto__

[liorean]

On 11/09/2007, Lars T Hansen <lth at acm.org> wrote:
> On the one hand, __proto__ is another potential security hole, and it
> prevents implementations from sharing prototype objects among multiple
> documents -- the link may be read-only but the object isn't.  Function
> B called from function A with object O may hack O.__proto__ and A can
> do nothing about it; suddenly all O-like objects in the system act
> differently.
>
> On the other hand, Constructor.prototype is generally available for
> any Constructor, so it's hard to see what the real damage is -- it's
> not obviously worse than some other aspects of the language.

For ES3 code, exposing __proto__ means that prototypes on constructors
protected by scope (as is becoming practice by at least library
writers today) are exposed, which they weren't before. It also means
that a prototype that is thrown away after setting up the object will
now be accessible.

> On the third hand, some implementations may have specialized objects
> for which no Constructor is available and for whom keeping
> [[Prototype]] unavailable is desirable.  Similarly, some toolkits may
> have private prototype objects that are not available to client code
> because the constructor is hidden in a lexical scope (ES3) or
> package/namespace (ES4).
>
> Introspection is great, but it assumes a lot about how trust works in
> the environment.

Hmm. On another note: Would it be reasonable to standardise a way to
attach a prototype chain to a plain object instanciator? (Instead of
reading one out of an object...)


    var
        someObject={
            mySharedValue: value},
        someOtherObject={
            "[[prototype]]": someObject};

This would get rid of the need for a function call (Crockford's object
function for instance) for setting up plain ES3 prototypal
inheritance, and would mean some structures that are not currently
serialisable as JSON despite being plain value structures would become
serialisable.
-- 
David "liorean" Andersson