Blocking tab-under navigations?

[domenic]

Transferring from WICG/interventions#66. Chromium has apparently shipped (edit: this is incorrect; see the following comments) some code to block navigations it considers "abusive tab-under navigations". The code says

// Currently, navigations are considered tab-unders if:
// 1. It is a navigation that is "suspicious"
//    a. It has no user gesture.
//    b. It is renderer-initiated.
//    c. It is cross site to the last committed URL in the tab.
//    d. The navigation started in the background.
// 2. The tab has opened a popup and hasn't received a user gesture since then.

There was some interest from Firefox at the time, in https://bugzilla.mozilla.org/show_bug.cgi?id=1406886, but the relevant people have moved on.

These are all relatively spec-able restrictions, if we wanted to do so. And apparently they're web-compatible.

It's not clear to me exactly what "blocked" means. Behaves like a 204? Or like a network error? Is there an interstitial? If this is in a popup, do we close the popup? But presumably it's pretty easy to find out. I will ask around.

If it's a network error, then one could argue that theoretically this is allowed by the spec already; there's nothing mandating that network errors actually come from the network. And I think this loophole is already used to slip in things like safe browsing checks.

So I see a few paths here:

• Do nothing, and say Chromium is OK to do this because it's just a sort of network error, and the spec already allows those.

• Be more explicit about codifying the ways in which navigation failures are allowed. E.g., add something to the navigate algorithm which has specific abort points either before the request or after receiving the response (perhaps after each response, in a redirect chain?) where the browser can explicitly choose to create a network error. This would then make it clearer where in the spec safe browsing occurs.

• (If other browsers are interested) Codify this specific behavior.

[domenic]

The design doc indicates the block is done similar to a 204 (stay on the previous page) plus some extra UI. That is not really allowed by current specs so it rules out the "do nothing" path.

However, the design doc also links to a demo site, https://cr.kungfoo.net/popups/tab_under/ , which I cannot get to trigger any such experience on Chrome desktop. So I am wondering now whether this feature is actually enabled or whether it has evolved since the design doc was written.

/cc @csharrison @jkarlin

[csharrison]

Hey @domenic, We never shipped the blocking behavior due to compatibility concerns mentioned in the interventions issue:

However, there are some legitimate use cases for tab-unders as currently defined. For instance, a site that opens popups (like a email site) might want to automatically redirect to a third party auth provider in the background when a session ends.

We never adequately resolved these issues, and so the current code in Chrome is still in "report-only" mode for downstream automated analysis.

Spec wise, I think this should be treated like a network error (e.g. set failure to true in process-a-navigate-response), we do have code to hook into the framebust blocking UX the Chrome ships which allows a user to "undo" a blocked navigation.

[domenic]

Ah OK, thanks for clarifying! (My incorrect skim of the code was that there was some class of pop-unders you wanted to block, but couldn't yet, and so in the meantime were just blocking a subset.)

That definitely decreases the urgency of any work here. We can use this spec issue to track any future progress, if Chrome or any other browser makes progress on the compat concerns.