W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2015

Re: @@symbol hooks and cross domain frames

From: Adam Klein <adamk@google.com>
Date: Thu, 16 Jul 2015 16:37:12 -0700
Message-ID: <CAEvLGc+V5qjbvsOrwJGvLVHXED7PyFX=iCZuqP1x_FfFmGeBSg@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: Erik Arvidsson <arv@google.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Caitlin Potter <caitpotter88@gmail.com>, Allen Wirfs-Brock <allenwb@mozilla.com>, Brian Terlson <brian.terlson@microsoft.com>, Bobby Holley <bholley@mozilla.com>
On Thu, Jul 9, 2015 at 2:22 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 7/9/15 5:16 PM, Adam Klein wrote:
>
>> What would HTML say about @@isConcatSpreadable on a same-origin window,
>> though?
>>
>
> I assume absolutely nothing, I would think.  Which means it would end up
> defaulting to undefined, unless a page deliberately sets it up on the
> window or somewhere up its prototype chain.
>
>  I had been imagining the solution might be to add an
>> [Unforgeable] @@isConcatSpreadable property to Window
>>
>
> Why do we want to prevent people opting same-origin windows into being
> concat-spreadable if they want to?
>
>      I think @@toStringTag should also simply return undefined on a
>>     cross-origin window.  This will give us the desired behavior of
>>     "[object Object]".
>>
>> This works a little better, in that window will have a @@toStringTag
>> property somewhere on its prototype chain, but it would actually need to
>> be on instances to return undefined before the security check kicks in.
>>
>
> Everything on cross-origin windows is on instances.  See the spec proposal
> at https://etherpad.mozilla.org/html5-cross-origin-objects that Bobby and
> abarth and hixie worked out a while back and hixie is working on writing up
> right now (c.f. <https://www.w3.org/Bugs/Public/show_bug.cgi?id=20701>).
>

Okay, I've read the etherpad, and feedback from other V8 folks who have
also read it suggests it's a good way forward.


> To be clear, my proposals for what to do with @@isConcatSpreadable and
> @@toStringTag assume that browsers are implementing what that etherpad
> says; they're quite simple to do in that world.


Can you sketch this in just slightly more detail? Yes, everything is on
instances. Additionally, any attempt to [[Get]] a data property
cross-origin fails. This suggests that Window (and Location) must have an
accessor property for @@isConcatSpreadable. Are you suggesting that that
getter should check whether the access is cross-origin and return undefined
in that case? What if the getter is called from a same-origin context? And
what does the setter do?

- Adam
Received on Thursday, 16 July 2015 23:37:41 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 16 July 2015 23:37:41 UTC