@torgo: We're filing this a bit later than we should have, but it would be helpful to get y'all's eyes on it sooner rather than later, as our implementation is underway, and we think it's on the critical path for deployment of this isolation primitive at scale (which, in turn, is blocking our ability to deprecate unsafe usage of SharedArrayBuffer-likes). Thanks!

I understand there's the precedent with CSP, but curious if there's another reason this is a separate header rather than a report-only flag on the normal COOP header?

We think it's valuable to be able to report upon one policy, while enforcing another. This gives folks the ability to migrate from the weaker same-origin-allow-popups to the stricter same-origin by enforcing the former, and reporting upon the latter. Once they drive the reports down to a point at which they're happy, they can enforce the latter.

It's certainly plausible to obtain this result by specifying the reported policy via a syntax that jammed everything into one header. I think we've taken a multi-header approach here (and in COEP) simply for consistency with things like CSP rather than any practical reason unique to this mechanism.

(It's not just consistency. It's also extensibility. If the policies would become more complex than an enum value that might become quite hard to handle.)

Thanks for the responses, we discussed this further and agree with the use case for a separate header. We're also fine with the current design.

Closing this as satisfied, thanks for flying TAG.