__proto__

Lars T Hansen lth at acm.org
Tue Sep 11 02:34:28 PDT 2007


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.

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.

--lars


On 9/11/07, Kris Zyp <kriszyp at xucia.com> wrote:
> > The alternative above would standardize read-only __proto__, which  would
> > make that property no longer implementation-specific. But of  course we
> > have no proposal to do that.
> I realize this wasn't really the main subject... but could the __proto__
> property be defined in the spec (as readonly)? I would love to see that
> property standardized.
> Kris
>
> _______________________________________________
> Es4-discuss mailing list
> Es4-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss
>



More information about the Es4-discuss mailing list