B.3.1 The __proto__ pseudo property

Mark S. Miller erights at google.com
Sun Apr 21 21:43:09 PDT 2013

On Sun, Apr 21, 2013 at 8:45 PM, Brendan Eich <brendan at mozilla.com> wrote:

> 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
>   delete Object.prototype.__proto__
> remove all the magic, including for 'o = {__proto__: p}'.

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.

> 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.

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.

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.

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.

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:

    { __proto__: { secret: "857234850349859234" }}

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.

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.

> /be
> Mark Miller wrote:
>> Hi Andrea, Allen's immediately previous sentence was
>> "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."
>> 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
>> 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.
>> 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.
>> 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.)
>> 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.
>> On Sun, Apr 21, 2013 at 6:47 PM, Andrea Giammarchi <
>> andrea.giammarchi at gmail.com <mailto:andrea.giammarchi@**gmail.com<andrea.giammarchi at gmail.com>>>
>> wrote:
>>     On Sun, Apr 21, 2013 at 6:11 PM, Allen Wirfs-Brock
>>     <allen at wirfs-brock.com <mailto:allen at wirfs-brock.com>**> wrote:
>>         We are free to specify a semantics that will make sense, now
>>         and for the long term.
>>     then, for the long term, if all I understood about this thing is
>>     that stinks for everybody, you should really consider to give
>>     developers the possibility to get rid of this property completely,
>>     if desired, instead of making it indestructible, IMHO
>>     ______________________________**_________________
>>     es-discuss mailing list
>>     es-discuss at mozilla.org <mailto:es-discuss at mozilla.org**>
>>     https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>> --
>> Text by me above is hereby placed in the public domain
>>   Cheers,
>>   --MarkM
> ______________________________**_________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130421/18acfa4b/attachment.html>

More information about the es-discuss mailing list