@yoavweiss

Do you happen to know the how HTTP enforcement and report-only headers interwork?

I think that

• you can have Cross-Origin-Opener-Policy and/or Cross-Origin-Opener-Policy-Report-Only headers on any document.
• The report(s) sent are from the perspective of the document with the policy and reporting endpoint.
• Violations are determined by comparing that documents policy (which may be enforced or report only or both) and the enforced policy of the other document (you're always comparing the reporting/enforce policy in the current document to the actual policy of the other document).

So say I have an opener with a Cross-Origin-Opener-Policy: same-site that includes a reporting endpoint, and there is a navigation to another document that in this case has no policy (so a policy of unsafe-none and no reporting endpoint)

• The policy will be evaluated and there is a violation because the opener is opened in a new BCD.
• As per https://github.com/mdn/content/pull/39880/files#r2151347130 I think a report will be sent to the reporting endpoint of the opener of type navigation-from-response.
• No report is sent for the opened.

Now consider the case where the opener still sets Cross-Origin-Opener-Policy: same-site but the opened sets Cross-Origin-Opener-Policy-Report-Only: same-site-no-opener and Cross-Origin-Opener-Policy-Report-Only: unsafe-none

• There is a policy violation because the opened is opened in a new BCG.
• I think a report will be sent to the reporting endpoint of the opener of type navigation-from-response.
• I think a two reports will be sent to the reporting endpoint of the "opened" document of type navigation-from-response.
• The first will be of disposition: enforced, and effectivePolicy unsafe-none
• The second will be of disposition: reporting, and effectivePolicy same-site-no-opener

I think that is what the spec says, and it makes sense to me.

I'll again have to call on @camillelamy for help here, as I'm not sure what the answer here should be.

So I wrote the spec for reporting in COOP and am much more familiar with the implementation, so this one I can answer.

For COOP, we try to see if a browsing context group would happen were we to enforce all the policies we're asked about.

In practice, we separate enforce/report-only mode (which can have different reporting endpoints).

For enforcement, we only compare with the other document enforced policy: we are reporting that a BCG switch did happen after all.

For report-only, this is a bit more complex. First, we check if the other document report-only policy would ensure that there would be no BCG swap. If that's the case, we won't send a report. Our rational is that developers might want to deploy COOP on several documents in their origin in report-only mode first, and we should not warn them about issues that would not happen if they switch all of their report-only policies to enforcement.

If the report-only don't match, then we check what would happen if we enforced the report-only policy of the document we're navigating to compared with the enforced policy of the current document. We also compare the report-only policy of the current document with the enforced policy of the document we're navigating to. If any of those would trigger a BCG swap, then we note that the documents would ned up in two different browsing contexts. We keep track of this information even if the documents navigate again, this is important for the access reporting. When the BCG switch would be triggered, we also send a report to the relevant endpoints of both the current document and the document we're navigating to. If there are no endpoints, then we don't send a response.

In your second example, you listed two report only policies so I am going to assume you meant unsafe-none as the enforced policy and same-origin-no-opener as the report-only one. In that case, you would get:

• You get a navigation-from-response report on the endpoint of the opener, with disposition enforced and policy same-origin.
• You get a navigation-to-response report on the enforced endpoint of the openee with disposition enforced and policy unsafe-none.
• You get a navigation-to-response report on the report-only endpoint of the openee with disposition report-only and policy same-origin-no-opener.

Now if the openee report-only policy was same-origin, and it was same-origin with the opener, you would not get the third report-only report. But you would still get the first two. And if both documents were same-origin and had report-only same-origin COOP, you would not get any report at all. If only one of them had the report-only COOP, then you would get reports.

This gets a bit more complex for access reporting, as we're keeping track of whether any report-only COOP would have triggered a BCG swap. Then when an access happen, we check if the two documents would be in different BCGs if COOP had been enforced. But the BCG swap might have been triggered during a previous navigation. To give you an example:

• You document has COOP report-only same-origin. It opens a popup with a cross-origin document. We record that all documents in the popup would be in a different BCG from the documents in the opener page if COOP was enforced. Accesses to the popup/from the popup are reported (provided they involve a same-origin document).
• The popup navigates to another origin. There is no new BCG switch due to COOP, but we would still report accesses because the pages would still be in different BCGs.
• The opener navigates to a non-COOP page. This would also trigger a BCG switch if COOP was enforced. We record this. However, we no longer have a reporting endpoint for COOP, so we don't send reports anymore.