Re: __proto__
Is __proto__ somehow a new security threat? __proto__ has been around for ages in SM/FF and not only that, but it has been there in the more hazardous writable form. I just wanted it be actually included in the spec. Or is there some new functionality in ES4 that will somehow interact with __proto__ to introduce a security threat? Kris - Original Message - From: Lars T Hansen [EMAIL PROTECTED] To: Kris Zyp [EMAIL PROTECTED] Cc: Brendan Eich [EMAIL PROTECTED]; liorean [EMAIL PROTECTED]; es4-discuss@mozilla.org Sent: Tuesday, September 11, 2007 2:34 AM Subject: Re: __proto__ 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 [EMAIL PROTECTED] 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@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: __proto__
__proto__ breaks abstraction boundaries in the language -- it's just like function.caller, you get to look at and change objects that your caller may wish to keep secret from you. Whether it's actually a security threat depends on the details of the environment: whether your caller fits those criteria or not, or whether your run-time environment has objects whose constructors are not exposed to client code. --lars On 9/11/07, Kris Zyp [EMAIL PROTECTED] wrote: Is __proto__ somehow a new security threat? __proto__ has been around for ages in SM/FF and not only that, but it has been there in the more hazardous writable form. I just wanted it be actually included in the spec. Or is there some new functionality in ES4 that will somehow interact with __proto__ to introduce a security threat? Kris - Original Message - From: Lars T Hansen [EMAIL PROTECTED] To: Kris Zyp [EMAIL PROTECTED] Cc: Brendan Eich [EMAIL PROTECTED]; liorean [EMAIL PROTECTED]; es4-discuss@mozilla.org Sent: Tuesday, September 11, 2007 2:34 AM Subject: Re: __proto__ 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 [EMAIL PROTECTED] 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@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Fwd: isPropertyEnumerable is going to stay broken?
(fwd to list)...
On 9/10/07, Brendan Eich [EMAIL PROTECTED] wrote:
On Sep 10, 2007, at 2:41 PM, Neil Mix wrote:
I think this is what Garrett is referring to:
js function f() {}
js f.prototype.foo = blah;
blah
js var x = new f();
js print(x.propertyIsEnumerable(foo));
false
js for (var n in x) print(n);
foo
And I have to agree with him, the method is confusing.
Sure, but that ship sailed (https://bugzilla.mozilla.org/show_bug.cgi?
id=57048#c4).
Based on its
name, I'd expect it to return true if the property can be enumerated
via for-in loop on the given object, regardless of where the property
exists in the prototype chain.
My question remains: is this an incompatible change that will help
more than it hurts, and otherwise be worth making?
Probably have more important things in the language.
I read that bug rep't and you stated in the last comment I still
think ECMA is wrong, and should be fixed.
I'm considering your question.
I would like it to be fixed, but can't say if it's the Right Thing.
I'll consider brining it up on c.l.j
I'm going to make a blog entry about it, too.
Garrett
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
