<div dir="ltr">On Sun, Apr 21, 2013 at 9:56 PM, Andrea Giammarchi <span dir="ltr"><<a href="mailto:andrea.giammarchi@gmail.com" target="_blank">andrea.giammarchi@gmail.com</a>></span> wrote:<br><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">if Object.getPrototypeOf() works there, how is that secret protected?</div></blockquote>
<div><br></div><div style>Assuming the script does not make the object that the literal evaluates to available to the hostile environment it is running it. This was always the delicate assumption of the old argument.</div>
<div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>In any case, do you agree since you can configure Object.prototype.__proto__ you could also poison it by your own instead of proposing an unusable poisoned setter as it is now in V8?</div>

<div><br></div><div>I am talking about this possibility (already in Firefox):</div><div><br></div><div><div class="im"><div style="font-family:arial,sans-serif;font-size:13px">var set = Object.getOwnPropertyDescriptor(</div>

<div style="font-family:arial,sans-serif;font-size:13px">      Object.prototype,</div><div style="font-family:arial,sans-serif;font-size:13px">      '__proto__'</div><div style="font-family:arial,sans-serif;font-size:13px">

    ).set;</div><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">delete Object.prototype.__proto__;</div><div style="font-family:arial,sans-serif;font-size:13px">

<br></div></div><div style="font-family:arial,sans-serif;font-size:13px">together with this for, eventually, SES</div><div class="im"><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">

<div>(function(getOwnPropertyDescriptor){</div><div>  Object.defineProperty(</div><div>    Object,</div><div>    'getOwnPropertyDescriptor',</div><div>    {</div><div>      enumerable: false,</div><div>      configurable: false,</div>

<div>      writable: false,</div><div>      value: function(object, property) {</div><div>        var d = getOwnPropertyDescriptor(object, property);</div><div>        if (d && property === '__proto__') {</div>

<div>          d.set = function () {</div><div>            throw new Error('nope');</div><div>          };</div><div>        }</div><div>      }</div><div>    }</div><div>  );</div><div>}(Object.getOwnPropertyDescriptor));</div>

</div><div style="font-family:arial,sans-serif;font-size:13px"><br></div></div><div style="font-family:arial,sans-serif;font-size:13px">So that whoever want to delete can reuse same "magic" and work in a __proto__ free environment, literals special syntax a part (don't care much, equivalent shortcut of Object.create() so it's OK)</div>

<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">What do you think?</div></div></div></blockquote><div><br></div><div><br></div><div style>I'm sorry, I don't get the point. What are you trying to demonstrate?</div>
<div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div> </div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra">
<br><br><div class="gmail_quote">
On Sun, Apr 21, 2013 at 9:43 PM, Mark S. Miller <span dir="ltr"><<a href="mailto:erights@google.com" target="_blank">erights@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr"><div>On Sun, Apr 21, 2013 at 8:45 PM, Brendan Eich <span dir="ltr"><<a href="mailto:brendan@mozilla.com" target="_blank">brendan@mozilla.com</a>></span> wrote:<br></div><div class="gmail_extra">
<div class="gmail_quote"><div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Andrea may be asking for less than the standard someday removing __proto__, if I read him right. He's asking not to keep it "indestructible", i.e., to make<br>



<br>
  delete Object.prototype.__proto__<br>
<br>
remove all the magic, including for 'o = {__proto__: p}'.<br></blockquote><div><br></div></div><div>Andrea, my apologies. I jumped into this thread in the middle and misinterpreted. I still don't like that idea, but not on the grounds previously stated.</div>

<div>
<div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
But that seems to require using [[Put]] rather than [[SetInheritance]], and you said that's a security problem. Could you show how? I asked in my immediately preceding message how creating custom proto-chains for guaranteed fresh objects via literals makes trouble for SES.<br>


</blockquote><div><br></div><div><br></div></div><div>I truly hate to make any security argument whatsoever based on the Same Origin Policy (SOP). However, one of the legacy constraints of the web we must respect is not to break security that was successfully built on the SOP, even if the form of security at stake was a twisted miserable affair. I agree that we should generally respect this constraint.</div>


<div><br></div><div>An old argument about the safety of having <script> tags do cross origin HTTP GETs without any special arrangement is that the requesting page could not *read* information contained in the script unless the script's behavior intends to reveal that information. I think this rationale was silly, as the script is being loaded into a potentially hostile environment that can already cause the script to behave in ways very different from its author's intentions. The counter-argument was that, at least literals themselves are safe. The counter-counter argument, presented as a vulnerability demonstrated by an attack (citation anyone?), is that on browsers with getters and setters, the ES3 literal-invokes-[[Put]] behavior enables the requestor to steal even information within JS literals. The argument should have stopped there, with the defenders of the SOP conceding that script tags allow cross origin reads with no further protection.</div>


<div><br></div><div>Instead, this continued to be seen as a meaningful vulnerability to be fixed. ES5 fixed this vulnerability regarding literals. In my opinion, I think this fix creates only confusion and a false sense of security. The script as a whole is still being loaded into a hostile environment, and it is not realistic to expect programmers to write interesting scripts that keep secrets when running in that environment. But I know of no way to get the advocates of the SOP to stop. Witness the recent agreement, without dissent, that a cross-origin module-source GET where the module loader is parameterized with the translate hook should require the special UMP/CORS permission. Whereas a cross-origin module-source GET without a translate hook does not need this permission.</div>


<div><br></div><div>Given that we are stuck with this as the explanation of browser security constraints, we at least need a simple line between what is and is not directly protected. With ES5 the line is "literals". This is simpler to understand than "literals that don't use the special __proto__ syntax." If programmers rely on this simpler explanation, the following literal should still be able to protect its secrets when loaded into a hostile environment:</div>


<div><br></div><div>    { __proto__: { secret: "857234850349859234" }}</div><div><br></div><div>My preference is that we get the world of the web to admit that there is no meaningful protection of a script's secrets from its loading environment. But I am not hopeful. In the absence of this agreement, we must not break the supposed security vulnerability that the web thinks we fixed in ES5. And so long as programmers are encouraged to count on this protection, we must not make the explanation of the delicate property they are counting on more complex than they will accurately remember.</div>


<div><br></div><div>The process of writing this down makes me even more aware of how convoluted it is. I retract my statement that "This is a big deal." I could probably be argued out of it if there was something significant to be gained. In this case, I don't think there is.</div>


<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>
<br>
/be<br>
<br>
Mark Miller wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
Hi Andrea, Allen's immediately previous sentence was<br>
<br>
"The point is that I don't think there is any long standing behavior in this regard relating to object literals and deleting Object.prototype.__proto__ that the web is dependent upon."<br>
<br>
This sets the context for understanding Allen's next sentence. We are constrained by cross-browser legacy. So long as IE was not planning to implement __proto__, we avoided standardizing it. In the current situation, TC39 is powerless to prevent __proto__ becoming a cross-browser standard. Our only choices are<br>



<br>
1) We design and codify a spec that all these browsers can agree on, that does not break existing cross-browser (IE aside) web content, and that is as clean as possible *within* those constraints.<br>
2) We do not do so, in which case each browser gropes separately to be compatible enough with what the other browsers seem to be doing.<br>
<br>
And example of the consequences of #2 is the wildly different and often bizarre semantics of block nested functions. This was the consequence of omitting these from "official" JavaScript in a social/political context where all browsers felt compelled to implement them anyway. They groped towards compatibility without coordination and arrived at painfully incoherent results. (Fortunately, we were able to quarantine this bizarreness to sloppy mode.)<br>



<br>
As a standards committee, we need to be realistic about when we can exercise normative power and when we can't. I'll even agree that, when we're uncertain, we should err on the side of cleaning things up. Until IE changed expectation, we were doing exactly that by avoiding __proto__. Today, we no longer have that happy uncertainty.<br>



<br>
<br>
<br></div><div>
On Sun, Apr 21, 2013 at 6:47 PM, Andrea Giammarchi <<a href="mailto:andrea.giammarchi@gmail.com" target="_blank">andrea.giammarchi@gmail.com</a> <mailto:<a href="mailto:andrea.giammarchi@gmail.com" target="_blank">andrea.giammarchi@<u></u>gmail.com</a>>> wrote:<br>



<br>
    On Sun, Apr 21, 2013 at 6:11 PM, Allen Wirfs-Brock<br></div><div>
    <<a href="mailto:allen@wirfs-brock.com" target="_blank">allen@wirfs-brock.com</a> <mailto:<a href="mailto:allen@wirfs-brock.com" target="_blank">allen@wirfs-brock.com</a>><u></u>> wrote:<br>
<br>
        We are free to specify a semantics that will make sense, now<br>
        and for the long term.<br>
<br>
<br>
    then, for the long term, if all I understood about this thing is<br>
    that stinks for everybody, you should really consider to give<br>
    developers the possibility to get rid of this property completely,<br>
    if desired, instead of making it indestructible, IMHO<br>
<br>
<br>
    ______________________________<u></u>_________________<br>
    es-discuss mailing list<br></div>
    <a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a> <mailto:<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><u></u>><div><br>
    <a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/<u></u>listinfo/es-discuss</a><br>
<br>
<br>
<br>
<br>
-- <br>
Text by me above is hereby placed in the public domain<br>
<br>
  Cheers,<br>
  --MarkM<br>
</div></blockquote></div></div><div><div><div><div>
______________________________<u></u>_________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
</div></div><a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/<u></u>listinfo/es-discuss</a><span><font color="#888888"><br>
</font></span></div></div></blockquote></div><span><font color="#888888"><br><br clear="all"><div><br></div>-- <br>    Cheers,<br>    --MarkM
</font></span></div></div>
<br>_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>    Cheers,<br>    --MarkM
</div></div>