+Nate and Ojan it looks like this is a one-liner addition to the Framebusting code [1]. What is the current status of that project? Do either of you have a sense of the feasibility for this restriction?

[1]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/frame/LocalFrame.cpp?rcl=38ead92c3968463939f32114da88812b01fd3e22&l=1039

Nevermind, I don't think this should be tied to Framebusting, which is restricted to when the target frame is at the top of the current frame tree (and not in a different window).

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/25672cf164676a4d621e54ceb2f1b912dbcf7493

commit 25672cf164676a4d621e54ceb2f1b912dbcf7493
Author: Charles Harrison <csharrison@chromium.org>
Date: Tue Feb 20 17:36:08 2018

Add UseCounter for cross origin nav on opener

Bug: 813643
Change-Id: I6cea489ba38ee181c49b54cb87b747db64a5ee63
Reviewed-on: https://chromium-review.googlesource.com/925622
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Commit-Queue: Charlie Harrison <csharrison@chromium.org>
Cr-Commit-Position: refs/heads/master@{#537810}
[modify] https://crrev.com/25672cf164676a4d621e54ceb2f1b912dbcf7493/third_party/WebKit/Source/core/frame/LocalFrame.cpp
[modify] https://crrev.com/25672cf164676a4d621e54ceb2f1b912dbcf7493/third_party/WebKit/public/platform/web_feature.mojom
[modify] https://crrev.com/25672cf164676a4d621e54ceb2f1b912dbcf7493/tools/metrics/histograms/enums.xml

Initial windows data from 66.0.3352.0 Canary shows ~.08% incidence rate from the CL in #4. Hopefully usage stays low and we can go through deprecation steps.

Ha, I was thinking .03% was our previous deprecation threshold, but it was .003%. Well, in any case still interesting to see what we can do. Maybe expose this to UKM for leads.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1ffb729d86a77d0cb70d445682d9e5970b972865

commit 1ffb729d86a77d0cb70d445682d9e5970b972865
Author: Charles Harrison <csharrison@chromium.org>
Date: Fri Feb 23 02:34:10 2018

Whitelist kOpenerNavigationWithoutGesture counter for UKM

This UseCounter tracks how often a frame tries to navigate its
opener (via window.opener) to a URL that is cross-origin to the
frame's URL, without a user gesture.

We want to remove this capability, but the counts are not quite low
enough to do it blindly (especially with the history of framebusting).

UKM will help guide the deprecation. We only have a single canary with
this feature but it appears to be pretty low incidence (<.1%).

Bug: 813643
Change-Id: I57237a793e56e80c5d3371964ba15e0965aafd44
Reviewed-on: https://chromium-review.googlesource.com/933021
Reviewed-by: Bryan McQuade <bmcquade@chromium.org>
Commit-Queue: Charlie Harrison <csharrison@chromium.org>
Cr-Commit-Position: refs/heads/master@{#538674}
[modify] https://crrev.com/1ffb729d86a77d0cb70d445682d9e5970b972865/chrome/browser/page_load_metrics/observers/use_counter/ukm_features.cc

Got some UKM data from the weekend. I think this will break lots of popup style logins which redirect the opener (and close themselves) after authentication. My guess is that for these cases we lose the user gesture due to:
a. Navigating the popup to some other document before redirecting the opener
b. Blocking on some network activity that could take longer than the gesture lifetime

A few options:
1. Only block the navigation if it is cross origin to *both* the target frame and the initiating frame.
2. Make this intervention opt-in. Not quite sure how this would work yet.
3. Use the framebusting notion of "frame ever had a gesture" rather than the typical transient gesture most features use.

jochen,mkwst: WDYT?

> 1. Only block the navigation if it is cross origin to *both* the target frame and the initiating frame.
Could that be bypassed if the origin has an open redirect?

> 2. Make this intervention opt-in. Not quite sure how this would work yet.
Maybe either through a response header from the server or by setting a certain request header if the navigation was initiated without user interaction?

> 3. Use the framebusting notion of "frame ever had a gesture" rather than the typical transient gesture most features use.
That would mean that this gesture could be used multiple times, right? In that case it wouldn't really protect against xs-search (b/72536296) since a single click by the victim would bypass the protection.

Yeah, most of these ideas sort of spoil the gains.
1. Hm... yeah if evil.com can navigate your opener to evil.com/redirect which does a client-side redirect to the original target then we're back to square one. I think that's what you mean by an "open" redirect? If it's a standard redirect we have an easier chance at catching it.

2. I think both of these could work. For the response header version, we'd probably have to be careful not to leak sensitive timing information in the initial response though. Potentially, could integrate with header-based feature policies.

For the request header idea, it's complicated because the definition of "user gesture" is non-standard and might not solve this. For instance, we have a "classic" user gesture which persists for 1s, but you can use it multiple times, so an attacker could send as many requests in 1s that may get marked as having a gesture. We need to make sure navigating window.opener "consumes" a gesture so it can't be re-used without another interaction.

3. Great point, it's a non-starter to think about relaxing this to allow multiple navigations with a single gesture.

> 1. Hm... yeah if evil.com can navigate your opener to evil.com/redirect which does a client-side redirect to the original target
I was thinking the other way round actually. evil.com will redirect window.opener from example.com to example.com/redirect?continue=evil.com. But your example makes more sense :)
But regardless of redirects, allowing redirecting if the destination is same-origin with the target window wouldn't protect against xs-search anymore since that's what an attacker would do. I.e. in an attack, I would trigger redirects like search.com/search?query=foo => search.com/search?query=bar.

The only difference from my perspective is that we could detect and block redirects from example.com/redirect?continue=evil.com to evil.com without a huge amount of extra work (though it would be much more complex than the current patch). As soon as we have a full page load things become harder to track though.

Still, you're right. I can try to go over the data to see if there are other solutions which would break less content like replacing "cross origin" with "different eTLD+1" or something. If we still end up hitting a wall we can explore opt-ins more deeply.

Here's an idea:
What if we just allowed you to navigate the opener at most once, and subsequent attempts are either blocked or require a gesture?

I suspect this won't break too many things while still providing decent protection.

That's a good idea.

There's also a proposal for a response header to isolate documents from cross-origin interactions that could be used to block redirects as well:
https://groups.google.com/a/chromium.org/forum/#!topic/isolation-policy/zueJF9ad20g

See https://github.com/w3c/webappsec/issues/139 for some related CSP discussion.