<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Jun 17, 2009, at 3:34 PM, Mark S. Miller wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Mon, Jun 15, 2009 at 9:23 PM, Brendan Eich <span dir="ltr">&lt;<a href="mailto:brendan@mozilla.com">brendan@mozilla.com</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); margin-top: 0pt; margin-right: 0pt; margin-bottom: 0pt; margin-left: 0.8ex; padding-left: 1ex; position: static; z-index: auto; "> <div style="">For ES5, this is a tempest in a teapot.<div><br></div><div>We at Mozilla are trying to remove assignable __proto__ in a near-term release, </div></div></blockquote><div><br>Hi Brendan, this is wonderful news!<br> <br>As reason for skepticism, our v8 folk cite<br> <br> &lt;<a href="http://www.google.dk/codesearch?q=%22__proto__+%3D+%22+lang:javascript">http://www.google.dk/codesearch?q="__proto__+%3D+"+lang:javascript</a>&gt;<br></div></div></blockquote><div><br></div>First page has a lot of Mozilla-only code, of course; I see caja.js at top of second page. We both should evangelize ES5 Object.create when it's ready.</div><div><br></div><div><br><blockquote type="cite"><div class="gmail_quote"><div>Nevertheless, I'm pleased to report that our v8 folks agree that if Mozilla does this and does not back off because of compatibility problems, they will do so as well. Thanks for being brave enough to jump into this pool first!<br></div></div></blockquote><div><br></div>Water's fine, really!</div><div><br></div><div><br><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); margin-top: 0pt; margin-right: 0pt; margin-bottom: 0pt; margin-left: 0.8ex; padding-left: 1ex; position: static; z-index: auto; "><div style=""><div>* A newborn with no other properties.</div><div></div></div></blockquote><div><br>For an object that never comes to have any own properties, when is it no longer a newborn?&nbsp; For example<br><br>&nbsp;&nbsp;&nbsp; function Token() {}<br> &nbsp;&nbsp;&nbsp; var tok = new Token();<br></div></div></blockquote><div><br></div>I didn't define that case fully, but what I had in mind was an object that has not yet gained "own" properties. Such an object might be accessible outside of a lexical scope, though, you're right. If that's a problem then escape analysis, which we are looking at for stack-based GC, might rescue this idea.</div><div><br></div><div><br><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); margin-top: 0pt; margin-right: 0pt; margin-bottom: 0pt; margin-left: 0.8ex; padding-left: 1ex; position: static; z-index: auto; "><div style=""><div>* A recent-born in the midst of initialization via evaluation of its object initialiser syntax, where the baby object can't escape, can't be referenced to make a cycle, etc.</div> <div></div></div></blockquote><div><br>How does this arise?<br></div></div></blockquote><div><br></div>var obj = {foo: 42, __proto__: bar};</div><div><br></div><div>Here the object has own properties, foo in this case. But it can't be referenced until after the entire initialiser has been evaluated.</div><div><br></div><div><br><blockquote type="cite"><div class="gmail_quote"><div>In both cases, would it be true that by the time Object.freeze(x) or Object.preventExtensions(x) returns that x no longer has a mutable [[Prototype]]?</div></div></blockquote><div><br></div>Yes, I agree with you about false [[Extensible]] making [[Prototype]] immutable. Nothing else makes sense.</div><div><br></div><div><br><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); margin-top: 0pt; margin-right: 0pt; margin-bottom: 0pt; margin-left: 0.8ex; padding-left: 1ex; position: static; z-index: auto; "><div style=""><div>ES5's Object.create relieves the need for any of this, but legacy code won't be rewritten all at once, so we're probably going to support the above two bulleted cases.</div><div> </div></div></blockquote><div><br>Given that this already isn't a problem for IE and Opera, that v8 follows your lead, and assuming that Apple does as well -- so that these two remain the only exceptions -- do you recommend that the spec adopt stronger wording? (I would find this attractive as well.) Any suggestions for what this stronger wording might be?<br></div></div></blockquote><div><br></div>It's too late for ES5. It would not necessarily have the effect we hope for, anyway. We need to try restricting assignments to __proto__ and see how that flies.</div><div><br></div><div><br><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); margin-top: 0pt; margin-right: 0pt; margin-bottom: 0pt; margin-left: 0.8ex; padding-left: 1ex; position: static; z-index: auto; "><div style=""><div>The idea that the ES5 spec suddenly makes the world more secure by trying circuitously to address old extensions such as __proto__ seems optimistic to me. Better to get rid of the offending extension than try to fence it while not speaking its (I mean ES-unspecififed __proto__'s) name.</div> <div></div></div></blockquote><div><br>Certainly! But until we see how your experiment goes (best of luck!) I am proceeding under the pessimistic assumption that we can't get rid of the offending extension from all ES5 implementations. I'd love to be proven wrong.<br></div></div></blockquote><div><br></div>We seem to agree, then. This is a matter of implementors reforming implementations, then the spec can follow.</div><div><br></div><div><br><blockquote type="cite"><div class="gmail_quote"><div>When implementations have bad features in common with each other,</div></div></blockquote><div><br></div>First, there are bad features in ES1-3 not in all implementations of those specs' eras. Nothing in the spec process magically precludes "bad", alas.</div><div><br></div><div>Second, bad de-facto standards may be too expensive to codify in a given period (including ES5, especially now). But that doesn't mean implementors can't launch reform initiatives, or web developers can't start reform movements.</div><div><br></div><div>Third, even if we could afford to simultaneously specify and deprecate or restrict (e.g., ban from strict mode) bad old forms in a next-gen de-jure standard, if there's no better way for developers to solve the problems they solved with the bad old forms, at least until the next-gen standard is adopted widely, then developers won't tolerate browser vendors breaking the platform the devs built upon, which the browser vendors purveyed.</div><div><br></div><div>I've written about using the carrot, then the stick. But the metaphor's wrong: TC39 or another standards body is no horse trainer, and developers are not horses. The mistakes made everywhere should motivate greater humility, in addition to staging of de-jure standards based on de-facto work.</div><div><br></div><div><br><blockquote type="cite"><div class="gmail_quote"><div> as</div><div> with F.caller, then some cross-browser code will have come to rely on<br> that feature. Then, even if each browser vendor individually believes that the web<br> would be better off without that feature, they are in the normal<br> browser competitive bind removing the feature. That's one of the major<br> purposes of standards committees -- to get de-jure agreement on<br> changes that all would like to make but that each would be punished<br> for making by themselves. I think this accurately describes why we<br> needed a de-jure poison pill for F.caller.<br></div></div></blockquote><div><br></div>It's plausible; I've talked about the Prisoner's DIlemma at work in the browser market.</div><div><br></div><div>However, until widely adopted, a "reformist" de-jure standard is toothless. In the present case it is Mozilla (and others who'll join us) who must take risk in the market trying to restrict assignable __proto__. Ecma TC39 via ES5 (even if it had started the effort in time) couldn't credibly ban assignable __proto__ in non-strict mode.</div><div><br></div><div><br></div><div><blockquote type="cite"><div class="gmail_quote"><div>Given the expanded threat model ES5 seems to enable (see the "Future defensibility from untranslated code" section at the bottom of &lt;<a href="http://code.google.com/p/google-caja/wiki/NiceNeighbor">http://code.google.com/p/google-caja/wiki/NiceNeighbor</a>&gt;), the F.caller issue, had it not been caught in time, would have cost us a factor of two in performance. The present issue, if unfixed, may well preclude this expansion of our threat model except on ES5 implementations that happen not to have this problem.<br></div></div></blockquote><div><br></div>I'm glad this was caught. We're just getting into strict mode implementation now, and we have an old access check in the SpiderMonkey F.caller code (Norris Boyd added this in the late '90s, for Netscape's signed script/applet security model), as I mentioned at the TC39 meeting. This suggests reviewing all access checks for strict mode relevance.</div><div><br></div><div>/be</div></body></html>