B.3.1 The __proto__ pseudo property

Andrea Giammarchi andrea.giammarchi at gmail.com
Sun Apr 21 21:56:24 PDT 2013

if Object.getPrototypeOf() works there, how is that secret protected?

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?

I am talking about this possibility (already in Firefox):

var set = Object.getOwnPropertyDescriptor(

delete Object.prototype.__proto__;

together with this for, eventually, SES

      enumerable: false,
      configurable: false,
      writable: false,
      value: function(object, property) {
        var d = getOwnPropertyDescriptor(object, property);
        if (d && property === '__proto__') {
          d.set = function () {
            throw new Error('nope');

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)

What do you think?

On Sun, Apr 21, 2013 at 9:43 PM, Mark S. Miller <erights at google.com> wrote:

> 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>
> --
>     Cheers,
>     --MarkM
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130421/cc92915e/attachment.html>

More information about the es-discuss mailing list