Disowning owner should perhaps affect link targeting

[bzbarsky]

Consider this document:

<div onclick="w = window.open('http://example.com', 'foo'); w.opener= null">
  Click me first
</div>
<div onclick="w = window.open('http://example.org', 'foo'); w.opener= null">
  Click me second
</div>

I believe per spec clicking the first link then the second one should only open one window, since disowning the owner doesn't affect link targeting as far as I can tell.

In both Gecko and Blink, two windows are opened instead.

In Edge only one window is opened and the second click doesn't navigate it (no matter what I do with the opener) which seems a bit odd.

[mikewest]

I prefer Gecko and Blink's current behavior, FWIW. That is, I agree that the spec should change.

[annevk]

I also get two windows for

<a rel=noreferrer target=x href=http://example.org>test</a>
<a rel=noreferrer target=x href=http://example.org>test</a>

and if I remove rel=noreferrer I no longer do.

When I do <a target=x href="data:text/html,<script>alert(opener)</script>">test</a> in Firefox I get a modal dialog asking whether I want to let the domain containing that link to control this tab. In Chrome this throws a security error of sorts rather than simply returning null.

Anyway, it seems pretty clear that not having an opener should affect link targeting.

I do get the same set of cookies if open about:blank with or without rel=noreferrer but there is no way to inspect this other than through the developer console. So about:blank inheriting a bunch of stuff should likely happen either way, although it is rather pointless since if you cannot access the window anymore you cannot navigate it anywhere or inject any kind of content.

window.name also seems preserved. Which makes it a one-way communication channel. Should we disable that for noopener or is that fine? I suspect folks might want to leak data to ads through other means than just Referer...

[annevk]

So @bzbarsky points out that an important factor here is same-origin vs cross-origin. E.g., in Gecko today

data:text/html,<a rel="noreferrer" href="about:blank" target="foo">Click me</a><a target="foo" href="javascript:/* oh, hello */">And then click me</a>

would likely let the javascript URL read all the inherited stuff from the about:blank context, even with rel=noreferrer.

[mikewest]

In an ideal world, I'd like to get to a place where noopener and noreferrer make it possible to put the new window in a completely separate process, even for same-origin documents. That means there must be no mechanism to gain direct DOM access to another same-origin window. With that in mind:

I also get two windows for

<a rel=noreferrer target=x href=http://example.org>test</a>
<a rel=noreferrer target=x href=http://example.org>test</a>

and if I remove rel=noreferrer I no longer do.

This seems like correct behavior to me. We want to decouple these windows, so they shouldn't be familiar with each other. If y'all agree, we'll need to change the "familiar with" definition to adjust the same-origin bit to exclude this case.

<a target=x href="data:text/html,<script>alert(opener)</script>">test</a>

Chrome throws an error because we treat data: as a unique origin.

window.name also seems preserved

It would be good to prevent this, as it would enable the opened window to gain access to a cooperative opener. I'd like to prevent this in the same way we'd prevent targeting the one window from the other.

data:text/html,Click meAnd then click me

Wouldn't the targeting change fix this? That is, "foo" != "foo" if the windows aren't familiar with each other.

[annevk]

I talked with @bzbarsky and we would be okay with changing our behavior for the same-origin case, to also not allow targeting by name there.

That would mean that the "familiar with" clause needs to change to "Either A is same-origin with B and neither A nor B is disowned, or", correct?

What is the reason for not setting window.name? How can a cooperative opener allow access?

[jeisinger]

In blink, we only do the lookup by frame name in the local process. So in all cases where we host the navigation in a different process, the lookup by name just never works.

Ideally, that would be spec'd somewhere :)

[annevk]

Agreed and that is what this issue is about. However, that does not mean that the browsing context name cannot be set for (what will be) a different process.

[jeisinger]

right

[bzbarsky]

I talked with @bzbarsky and we would be okay with changing our behavior for the same-origin case

Specifically, I would be OK with changing to a behavior that is (1) unambiguously specified (which I don't think the current spec is, nor is Chrome's "local process" thing, since nothing defines what does and doesn't share processes in Chrome, and in fact it depends on various runtime things like how many processes are live already, last I checked) and (2) very likely to actually be web-compatible (because I don't want to change this behavior more than once).

[bzbarsky]

Put another way, we need to prevent targeting by name in the same process for same-origin stuff in some cases to have a well-defined spec here that doesn't depend on arbitrary implementation details.

[annevk]

I updated the patch in #313 to do that. I also posted an update there on the test front: #323 (comment). Input appreciated.

[annevk]

Instead of adjusting "familiar with", how about noopener effectively ends up creating a new "unit of related browsing contexts" and name targeting only searches within that unit (per #1440)?

As long as we then restrict "familiar with" to play within a "unit of related browsing contexts" I think we're good and don't run into the numerous complications I ran into with my PR.

@bzbarsky does that make sense?

[bzbarsky]

This issue is explicitly about disowning openers via setting window.opener = null (which is under the control of the thing that was opened), not noopener (which is under the control of the thing doing the opening). They're not the same thing.

I'm happy to discuss noopener behavior in #1826 if you would like.

[annevk]

Sorry.

For this issue, if I refactored the specification sufficiently such that I can allocate "unit of related browsing contexts" and I refactored that so it actually consists of a set of browsing context trees (which I think is what implementations do), I could allocate a new unit of related browsing contexts and just move one item of the set (whose top-level browsing context's window's opener was set to null) to this new unit.

Or would we then end up with more separation than we'd like? (Reading through #323 it seems like this might be okay, but maybe things have changed.)

[annevk]

I guess that setup doesn't quite work when A creates auxiliary B and B creates auxiliary C and then B sets opener to null. You'd then want (A), (B, C) I think, although it gets weird if A already accessed (nested) bits of B or C.

[annevk]

Anyway, if we can figure out the actual structure of a "unit of related browsing contexts" (tab group in Firefox, dunno about Chrome), we can then debate how to divide it and whether that works or whether we'll need some access restrictions on top of that structure for a couple special cases (such as link targeting). Hopefully that makes sense.

[bzbarsky]

I think there are two separate concepts here:

1. Which things might conceivably be able to target each other, assuming all documents involved are same-origin? Using "unit of related browsing contexts" is convenient here in that it's an existing spec concept. But note that I think the unit of related browsing contexts a browsing context belongs to should be determined at browsing context creation time. Moving a thing from one unit of related browsing contexts to another dynamically probably does not interact well with allowing implementations to have a separate event loop for every unit of related browsing contexts, and allowing that is a pretty explicit goal in the spec. Indeed, the spec aims to allow a separate event loop for every "unit of related similar-origin browsing contexts"; I'm not sure whether it succeeds. So if we want opener-disowning to affect targeting in the same-origin case, then using "unit of related browsing contexts" probably doesn't do what we want.

2. When different-origin documents are involved, what additional checks are done within the unit of related browsing contexts in terms of targeting? Are these checks affected by whether openers have been disowned or not?

[annevk]

I think the event loop, if Chrome's out-of-process-iframe experiments continue well, ends up being scoped to similar-origin window agent, which is a "subset" of "unit related browsing contexts" (currently called "unit of related similar-origin browsing contexts" though that is a bit of a misnomer as it's really documents/windows, not browsing contexts).

So splitting "unit of related browsing contexts" could work out and my main goal there was mostly that it would be a little cleaner and potentially have benefits beyond link targeting (although I'm not sure which, granted).

Anyway, even if that cannot work, defining the layout of a "unit of related browsing contexts" would help a lot. In particular if it's a collection of browsing context trees (root of which is auxiliary or top-level browsing context) we could give each item in that collection a flag and make it very clear how accessing between them goes.

[annevk]

A browsing context tree is the wrong model as child browsing contexts are tied to a document (or element, really), not a browsing context.

[bzbarsky]

Gecko's current behavior is as follows, ignoring the special _blank, _parent, _top names:

First, we define a CanAccess primitive which takes as input two browsing
contexts: a target and a source. It is implemented as follows:

1. If no source provided (not sure whether this can happen in a web context), return true.
2. If source and target are the same object, return true.
   • Browsing contexts can target themselves.
3. If source is a nested browsing context and target is an ancestor of source and target is a top-level browsing context, return true.
   • Frames can target their top-level browsing context.
4. If source's active document is same-origin with the active document of target or some ancestor browsing context of target, return true. There are some complications here around file:// URIs.
   • Documents can target documents that are same-origin or nested through same-origin documents. Except that's not quite what this implements, because it walks browsing context parent chains, not nesting chains. But maybe we don't reach this for browsing contexts that are nested through inactive documents...
5. If target is not a toplevel browsing context, return false.
   • Can't target subframes in cases not covered above.
6. If target is not an auxiliary browsing context, return false.
   • Can't target random non-same-origin top-level browsing contexts.
7. Repeat steps 1-4 with the same source but target set to target's window's opener's browsing context, if target's window has an opener. This can be affected by .opener = null calls, so doesn't match the concept of "opener browsing context" in the spec, I think! Might return from this algorithm.
   • Can target an auxiliary browsing context if we can target its opener But this only goes back "one level", so to say: we never examine the opener's opener.
8. Return false.

Note that I can't claim that this CanAccess is at all principled. It sort of
started out as return true and then various restrictions were added to it to
prevent specific attacks while trying to not break web compat. It might well be
too tight or too loose or both in various cases.

Armed with this CanAccess, we can define IsValidTarget which takes a browsing
context "source", a browsing context "target", and a string "name" and does:

1. If target's name is not "name", return false.
2. If CanAccess(target, source) returns false, return false.
3. Return true.

the named target search for a string "name" now works like this:

1. Set "source" to be the source browsing context for the search. For targeted
   form submissions and link clicks this is the browsing context of the node's
   document. For window.open this is the browsing context of the "this" object.
   Though there is some weirdness around the entry global's browsing context in
   here too, to decide whether we're opening a new window. Chances are, there are
   bugs around this stuff when document.domain is involved, in Firefox.

2. Check whether IsValidTarget(source, source, name). If true, return source.

3. For all descendants of "source", in depth-first preorder, check whether
   IsValidTarget(source, descendant, name). If true, return descendant.

4. Repeat the search for all ancestors of "source", in each case skipping all
   browsing contexts we have already considered and doing depth-first preorder
   walks on the browsing context tree. If any browsing context there returns true
   from IsValidTarget(), return it. So this considers the parent of "source", then
   all the parent's descendants that we haven't looked at yet, then the
   grandparent, then all its descendants, etc.

5. If nothing has been found so far, repeat the walk starting at all the
   toplevel browsing contexts in the same unit of related browsing contexts, in
   some order. Again, check IsValidTarget each time, return if something is found.

6. Return null.

[mystor]

Thanks for writing this up! It's good to know that my understanding of our algorithm wasn't too far off :-)

If source's active document is same-origin with the active document of target or some ancestor browsing context of target, return true. There are some complications here around file:// URIs.

* Documents can target documents that are same-origin or nested through same-origin documents.  Except that's not quite what this implements, because it walks browsing context parent chains, not nesting chains. But maybe we don't reach this for browsing contexts that are nested through inactive documents...

For inactive documents here, are your referring to documents in the BFCache? IIRC currently we consider documents framed by a cached document to not have a parent, meaning that they wouldn't be able to target their _top. We might still be able to target auxiliary browsing contexts, however.

[bzbarsky]

For inactive documents here, are your referring to documents in the BFCache?

Yes, or just unloaded in general.

[annevk]

The above algorithm also needs to be influenced by window.close() as that'll remove a browsing context from consideration despite it not being discarded yet. (#4402 adds an "is closing" boolean for this additional branch.)