Reporting for windows opened by cross-origin frames

[arturjanc]

The explainer says:

In particular, we cannot report that a popup was opened with rel-noopener due to COOP. This would give too much information about the behavior of cross-origin frames. Depending on who would enable reporting, we would leak:

• that a cross-origin iframe tried to open a popup to the parent document having enabled COOP reporting
• that the iframe was embedded in a "same-origin" COOP document to the iframe having enabled COOP reporting

Is there any reporting information any of the parties involved will get when a cross-origin iframe in a document with COOP opens a popup? I wondering about a case where an OAuth provider has a "Sign in with X" button which is loaded in an iframe and whether we can tell the embedding application anything about the resulting breakage (presumably when the popup opened from the iframe tries to communicate back with the iframe or its top-level document.)

If the answer is "no", could we do something to make reporting possible here? As one, example, if I have a iframeable widget, could I set an explicit COOP of unsafe-none, or a new COOP value (e.g. unsafe-none-allow-reporting) to allow my embedder to get information about COOP violations from popups opened from my widget as if the embedder opened them directly?

(Also, a nit: I don't understand the second bullet point above -- an iframe can always know if it's embedded same-origin.)

[arturjanc]

@annevk

[camillelamy]

The second bullet point is: the iframe gets to know that it was embedded in a cross-origin document with a top-level COOP policy of same-origin.

[arturjanc]

the iframe gets to know that it was embedded in a cross-origin document with a top-level COOP policy of same-origin

Isn't this something that we're revealing anyway? That is, if you open a new window by clicking in a cross-origin iframe, the iframe will be able to infer that the parent set a COOP of same-origin because it will lose a reference to the opened window (and if the parent doesn't have COOP, it won't lose the reference).

Basically, I think we could address this while exposing either minimal or no new information cross-origin, and make reporting more robust; this case seems important because the cross-origin frame scenario will likely appear in practice.

[camillelamy]

The problem though is where do you specify this kind of reporting, and how actionable it is.

If we report to the page with COOP we are leaking information about what the subframe is doing (ie it tried to open a popup).

If we want the subframe to have its own reporting, then we need to start taking into account COOP headers for subframes (which we don't do right now), but only for reporting. This adds a bit of complexity. On top of that, the only thing we can tell is that the subframe was embedded by a cross-origin frame with COOP same-origin and it couldn't open a popup and keep a reference to it. Since we can't provide the origin of the top-level frame, I am not sure this is very useful to report.

Maybe we should have a way for frames to specify that they do not want to be embedded in a COOP same-origin context. This is information we could provide to their embedder, and it would be more actionable than what we can provide with COOP reporting for this particular case.

[arturjanc]

Putting the infoleak aside for a moment, I think the most natural model here is the first one, i.e. reporting to the parent which sets COOP that a cross-origin iframe opened a popup (or, in other words, treating a pop-up opened by a cross-origin frame the same as one opened by the main document for the purposes of reporting).

IMHO this makes sense conceptually because COOP is controlled by the top-level window, so reporting should also be tied to that window. Practically, we'll want to report violations to the owner of the top-level document because this is the developer responsible for setting COOP, and setting COOP is the action with breakage potential that we want to surface with reporting. I don't think we could expect owners of iframeable resources to collect COOP violations and share them with their embedders.

When it comes to the information leak, I understand that it's a tough argument to make, but I think the impact of this particular leak is minor; on balance, my guess is that increased deployability of COOP due to more accurate reporting is better for the security of the web, even at a cost of introducing this infoleak. My reasoning is as follows:

1. The leak only happens if an iframeable page opens a pop-up and communicates with it.
2. Authenticated applications with sensitive actions susceptible to clickjacking already have to prevent themselves from being iframed and thus commonly set X-Frame-Options / frame-ancestors. Also, in the SameSite-by-default / credential double-keyed world the frame will be unauthenticated and its contents will be identical for all users, unless the site explicitly opts out.
3. If a document is embeddable, the embedder can already track the user's interactions with the embedded document by creating invisible overlays over the frame and hijacking mouse/keyboard events. So if the user clicks a button in the iframe which results in a pop-up being opened, the embedding page already knows about the user's click (though it currently cannot know if the pop-up really opened or not).

So, while I definitely agree this would leak data cross-origin, I'm having a difficult time finding a real situation where this would be a problem. If we think this is too optimistic I guess we could consider an opt-in/opt-out model, but - as above - I find it somewhat unlikely that providers of embedded resources would be inclined to do work to help their embedders deploy COOP.

@mikewest

[annevk]

I think the problem is that it reveals an action the user took. And 3 isn't necessarily true anymore with intersection observer, right?

[arturjanc]

I think 3 is still true in the sense that the embedder can know exactly where the user clicked in the iframe. They just don't know what happened as a result of the click, e.g. perhaps the frame decided to ignore it for some reason (possibly because it knows it's being obscured by the embedder by using the intersection observer). Reporting on COOP would reveal that information if the action results in opening a new window.