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

On Fri, Oct 16, 2015 at 12:58 PM, Anne van Kesteren <annevk@annevk.nl>
wrote:

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

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


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