Feature proposal: COEP/COOP reflection.

[ArthurSonzogni]

As part of the AnonymousIframe proposal, I am planning to add a way to reflect the COEP policy. However, I would be interested getting your opinions about how such API should look like? I would like to avoid future regrets and get something that would fit nicely together.

No need for COOP reflection for now, but I believe we should think about it anyway, so that both can eventually be used in a consistent manner, if added.

There are already:

window.isSecureContext
window.crossOriginIsolated

If we want to follow a similar pattern, the API could be:

window.crossOriginEmbedderPolicy == 'unsafe-none' | 'credentialless' | 'require-corp'
window.crossOriginOpenerPolicy == 'unsafe-none' | 'same-origin' | 'same-origin-allow-popups'

I am a bit sad about polluting the global object further, and worry about an eventual poor extendability.
Does this shape looks good to you? Would you had opinions about how the API should look like?

+CC @annevk, @domenic, @mikewest, @camillelamy

Motivation:
For trying Anonymous Iframe, Google DisplayAds, needs a way to know the COEP policy. The Ads's script could this way be able to decide in between inserting a normal or anonymous iframe.
Anonymous iframe is the only way for them to insert iframe inside a COEP: require-corp or COEP: credentialless context. However, it comes with the benefits/drawback of starting from a fresh ephemeral context every time.
They would like not to use it when it is not a necessity. They would like not to affect existing clients where this is currently working, the ones not using COEP.

[domenic]

This shape looks good to me. The global object is a fine place for new APIs.

[mikewest]

Given that these are all getting wrapped up in a "policy container" concept in HTML, I wonder whether it makes sense to put them together in that form from the developer perspective. That would (eventually) also let us shift things like document.featurePolicy.features and similar into a window.policies(?) container that would only add one item to the global object.

I can imagine that being a little too much, and it's certainly reasonable to just add one-off enums when we need them, but given the value of adding structure to HTML's understanding of these concepts, it makes sense to consider doing the same for developers.

[annevk]

I think I saw that anonymous iframes also offers a new request header. That should maybe be discussed at the same time as well as whether we want to expose this state to service workers through the Request object? As in, ideally these all have somewhat compatible shapes and extension points.

[ArthurSonzogni]

I think I saw that anonymous iframes also offers a new request header.

Indeed, this was in Camille's initial explainer. However it's not implemented and I haven't put it in the specification.

Developers seems interested using a JS API instead. We can do both for sure, but given the cost of sending additional bytes for every subresources, I was wondering if this was really worth it. I was happy deferring it up until somebody really can't do without it.

I don't have a strong opinion about the HTTP header, or the shape of the JS API. Happy to agree with anyone else with a stronger opinion/arguments ;-)