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.