Re: Defining exotic objects in IDL, HTML, or both?

On Fri, Oct 16, 2015 at 10:45 PM, Bobby Holley <bholley@mozilla.com> wrote:
> On Fri, Oct 16, 2015 at 12:58 PM, Anne van Kesteren <annevk@annevk.nl>
> wrote:
>> Hmm. One problem with the proposed design (assuming we're not defining
>> compartments in the specification) is that it overrides === which TC39
>> would not be happy with. Not having to do that would be preferable I
>> think. === works fine for Window since there's WindowProxy. It seems
>> like Location would need something similar.
>
> It may, at least conceptually, but I'm kind of loathe to do that just for
> document.domain.
>
> Basically, the one piece of magical behavior here is that, when Document a
> grabs a reference |x| to cross-origin Document b's location, and then both
> Documents become same-origin via Document.domain, |x| suddenly points to the
> now-accessible b.location. Furthermore, any method pulled off of |x| before
> a given change in document.domain retains its distinct identity.
>
> This is all nasty and document.domain-specific, so it really sucks to
> complicate the spec model further on its account. But maybe it can't be
> helped.

It does seem that if we are to specify Location in terms of ECMAScript
and, as you said elsewhere, the separate cross-origin objects are not
actually observable since [[Set]] throws, we could maybe get away with
a simpler model. Where the internal methods of the object simply
branch on same-origin vs cross-origin and then do the right thing.

E.g., [[GetPrototypeOf]] would return null when cross-origin, but
would return the Location prototype object when same-origin. And since
Location is marked [Unforgeable] it doesn't even have much of a
prototype object to speak of. Everything interesting are own
properties.

I realize this does not match what Adam Barth wanted, but it does seem
to preserve the invariants from the Etherpad while also resulting in a
sane specification that adheres to the invariants valued by
ECMAScript/TC39. And since it should have the same observable outcome
(unless I missed something, which I might well have) in terms of tests
and behavior, everyone can still keep their respective implementation
strategies.

(document.domain revoking access remains unaddressed, but personally I
have a hard time seeing that as a important security hole.)


-- 
https://annevankesteren.nl/

Received on Sunday, 18 October 2015 11:22:31 UTC