Report COEP violations in nested frame loading

[yutakahirano]

Modify the "check a navigation response’s adherence to its
embedder’s policy" logic so as to report (possibly potential)
COEP violations.

[yutakahirano]

@mikewest @annevk PTAL.

Notes:

Child frame's "report only value" is not taken into account because we block the navigation only when the child's policy is "unsafe-none", and we cannot attach a reporting endpoint when the value is "unsafe-none"

We attach "child cross-origin-embedder-policy" and "child cross-origin-embedder-policy (report only)" only when the report is made for "report only". Let's think about the following example:

parent:

• Cross-Origin-Embedder-Policy: <missing>
• Cross-Origin-Embedder-Policy-Report-Only: require-corp; endpoint="e1"

child (response):

• Cross-Origin-Embedder-Policy: <missing>
• Cross-Origin-Embedder-Policy-Report-Only: require-corp; endpoint="e2"

If the site owner updates the policy for the parent and the child at the same time, or update the policy for the child first, that should not be a problem. On the other hand, when the site owner updates the policy for the parent first, we'll see a block, so it is correct to report the potential blocking.

The user agent doesn't know the site owner's plan, so we report the case with COEP values so that the site owner can decide whether to take an action on or ignore the report.

[yutakahirano]

ping

[yutakahirano]

ping

[mikewest]

Generally looks pretty good! Small comments.

[mikewest]

Do we need to reveal this? I don't think there's much risk in saying that the resource asserted same-origin vs same-site, but it doesn't seem like we should be giving that information away cross-origin in the first place.

[mikewest]

@arturjanc to have an opinion about this (or delegate!) from the server-side.

[yutakahirano]

Ah good point. @annevk is concerned about leaking information through redirects. On the other hand, if we reveal COEP values only when the request's url is same origin with the origin of the parent context, that reveals one-bit information, same-originness. Is it too subtle?

I'm fine with revealing the COEP values only when the request's url is same origin with the origin of the parent context.

[mikewest]

I'm asking whether we need to reveal the value at all. "It doesn't match, otherwise I wouldn't be getting this violation report." seems like enough?

[yutakahirano]

I stated why this information is needed at #10 (comment) .

[yutakahirano]

Mike, does my above comment answer your question?

[mikewest]

It doesn't, unfortunately. But let's land this as-is and argue about this detail offline. :)

[annevk]

The user agent doesn't know the site owner's plan, so we report the case with COEP values so that the site owner can decide whether to take an action on or ignore the report.

I don't understand what this is saying.

[yutakahirano]

The user agent doesn't know the site owner's plan, so we report the case with COEP values so that the site owner can decide whether to take an action on or ignore the report.

I don't understand what this is saying.

Does the previous paragraph make sense to you?

If the site owner updates the policy for the parent and the child at the same time, or update the policy for the child first, that should not be a problem. On the other hand, when the site owner updates the policy for the parent first, we'll see a block, so it is correct to report the potential blocking.

[annevk]

I see. Yeah, we should report when there would be a block (and not make that depend on report only values or some such).

[annevk]

I guess I don't see how it relates to needing to report the actual COEP values though. The result being blocked or allowed seems sufficient?

[yutakahirano]

Hmm, then the site owner needs to filter out reports by looking at "url" and "blocked-url". And that sounds OK. I'll remove the policy part.

[yutakahirano]

Done. @annevk, can you take a look again?

[annevk]

I share Mike's concern about the logic duplication. It seems we should be able to do this in a single pass whereby the reporting and actual blocking are both conditional on what policy is in effect.

[yutakahirano]

I share Mike's concern about the logic duplication. It seems we should be able to do this in a single pass whereby the reporting and actual blocking are both conditional on what policy is in effect.

Done. @annevk, can you take a look again?

[yutakahirano]

Let me land this for now. If you have further comments please let me know, I'll be happy to address them.