__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