W3C home > Mailing lists > Public > www-archive@w3.org > October 2015

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

From: Bobby Holley <bholley@mozilla.com>
Date: Fri, 16 Oct 2015 13:45:05 -0700
Message-ID: <CAKBxTcLLRZ8B3g-X7ga3KOxQA4waniytWT0iusCx5dHtLN1h_g@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Bobby Holley <bholley@mozilla.com>, Boris Zbarsky <bzbarsky@mit.edu>, Domenic Denicola <d@domenic.me>, Cameron McCormack <cam@mcc.id.au>, www-archive <www-archive@w3.org>
On Fri, Oct 16, 2015 at 12:58 PM, Anne van Kesteren <annevk@annevk.nl>

> On Fri, Oct 16, 2015 at 8:12 PM, Bobby Holley <bholley@mozilla.com> wrote:
> > On Fri, Oct 16, 2015 at 10:56 AM, Anne van Kesteren <annevk@annevk.nl>
> > wrote:
> >> E.g., that same-origin Location objects still need security checks was
> >> not listed.
> >
> > That's a property of the Location object, not of the behavior of
> > cross-origin objects.
> I guess that is true, so we wouldn't want them to behave identical
> under those circumstances? It's fine for the Location object to still
> have "expandos", to have a prototype object of sorts, etc. And to be
> clear, this is also not stipulated, cross-origin Location objects can
> only come from WindowProxy, right?
> Or does Chrome also consider the case where document.domain "revokes"
> access and therefore document.location should return a cross-origin
> Location object? (Whereas that would throw in Gecko because nothing on
> document is whitelisted once it's in its security wrapper.)

I didn't grok this question, but we discussed in on IRC and sorted things

> The origin of the 'minting' concept was to be safe-by-default in case the
> > spec missed a corner case. The idea is that the spec can offer the basic
> > invariant that "No ES object from one origin should ever be exposed to
> > another origin", and engines can assume that the spec will never require
> > them to do that (which was important to Adam). This is less important
> than
> > Gecko thanks to wrappes, so we ignore this under the hood. But the idea
> is
> > that this should never be observable.
> 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

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

> > I am not aware of any problems that navigation might cause. Can you be
> more
> > specific?
> bz mentioned this. But I think what happened in his scenario was that
> you'd get a reference to a WindowProxy that would end up referring to
> a cross-origin Window object. So maybe that doesn't matter much.

Ok. I still don't follow the scenario being discussed, but I'm happy to
ignore it if it's a non-issue.
Received on Friday, 16 October 2015 20:45:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:35:26 UTC