I don't understand this sentence.

This seems to assume that browsing contexts with an opener are the top-level browsing context. That doesn't have to be the case.

For the violations:

• access-to-coop-page-from-openee we reports the openeeURL
• access-to-coop-page-from-opener we reports the openerURL

This should be the opposite. This is likely a copy-pasting error from "access-from-coop-page-to-{openee,opener}".
The same way, "referrer" and "initialPopupURL" might have to be exchanged in the explainer.

In this section https://github.com/camillelamy/explainers/blob/master/coop_reporting.md#virtual-browsing-context-group-id:

I understand the behavior of the first two, but I'm lost on diagrams 3 and 4. Specifically, why is there a BCG switch after the first navigation (BCG4 to BCG2)? Also, why is the first window in BCG4?

I expect this is correct and I'm just missing something; maybe it would be helpful to explain the interactions that are happening below each diagram?

From the explainer, it looks like top-level frame doesn't need to be anonymous (i.e. can have access to sensitive data/storage).
In a scenario where UA doesn't support OOPIF, how is the data in top-level frame protected from an anonymous iframe (if the anonymous iframe was evil)?

Should an iframe loaded inside a page with COEP: credentialless be automatically anonymous, or does it have to specify the attribute credentials=omit explicitly?

The former matches better the behaviour of other subresources and could be a bit easier to deploy.

But if we go with the former, would that be a way to override it, like specifying credentials=include?

If you navigate from A to B which redirects to C, why would we compare A, B, and C? Why not first compare A and B and report, and then compare B and C and report? That's also how the specification handles the switching and redirects could perfectly carry the reporting headers.

That would reduce the conceptual complexity a bit I think.

We only send violation reports for accesses to cross-origin properties, as we think websites will deploy COOP on all pages coming from the same origin, meaning that cross-origin accesses to cross-origin properties is where the bulk of the violations will occur.

This would be nice to also mention in the "Limitations of the API" section at the end because there will be cases where developers don't set COOP for all documents in a given origin.

Come to think of it, that final section could benefit from some structure and an explicit list of the situations where we know COOP reporting is imperfect, to help developers who don't have the context understand what they may be missing.

https://github.com/camillelamy/explainers/blob/master/coop_reporting.md#windowproxy-changes uses two phrases

WindowProxy's top level browsing context's

and

the environment's top-level browsing context

The first of these is well-defined (in that WindowProxys are 1:1 with browsing contexts and every browsing context has a TLBC). The second is less clear to me. Is it just meant to be a synonym for the first, or something else?

https://github.com/camillelamy/explainers/blob/master/coop_reporting.md#windowproxy-changes

This mentions "the property being accessed". But it would be good to detail which cases of WindowProxy access you are planning to hook, either specifically in terms of the different internal methods at https://html.spec.whatwg.org/#the-windowproxy-exotic-object, or just in general terms.

Since you are talking about properties, I am assuming you want to hook window.foo and window.foo = bar. But there are several other operations that deal with properties, namely Object.getOwnPropertyDescriptor(window, "foo"), Object.defineProperty(window, "foo", { value: bar }), and delete window.foo. There's also Object.getOwnPropertyNames(window).

Finally, it's worth detailing what you plan to do for the special cross-origin properties listed at https://html.spec.whatwg.org/#crossoriginproperties-(-o-) which are always accessible cross-origin, as well as for the special properties listed in https://html.spec.whatwg.org/#crossoriginpropertyfallback-(-p-) which are not accessible cross-origin but for which we intentionally ignore access instead of throwing.

Why is the bookkeeping on the top-level browsing context and not the top-level document? Storing it on the browsing context means we have to explicitly clear this state upon navigation which seems error prone.

Why not always use the referrer? If a site includes user information in the URL sometimes they might not wish for that to go into their COOP logs and it seems there's no way to prevent that with the current setup.

I'm a little worried about this design spanning the entire browsing context tree. I recall discussing a much simpler version with @arturjanc.

And I think it was very similar to navigations. "Someone is accessing me" and "I'm accessing someone else". What motivated the design change?

https://github.com/camillelamy/explainers/blob/master/coop_reporting.md#reporting-browsing-context-switches

• Some of these keys contain spaces. Is that intentional? JSON objects are usually underscore-delimited
• uri should be url, per https://url.spec.whatwg.org/#url-apis-elsewhere
• I'm unsure about the "disposition" field. COEP reporting does not include something similar, but I think CSP does. @yutakahirano, should these be aligned?
• "Note that effective policy can be same-origin-plus-coep". In the HTML PR we spelled this with a capital COEP. Maybe we should correct the HTML PR to align the casing, either now or when we work on reporting.

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.)

See this discussion:
https://chromium-review.googlesource.com/c/chromium/src/+/3161670

It is possible to create document that aren't the initial empty document nor the ones created by the navigation.
For instance:

• document.implementation.createDocument(...);
• document.implementation.createHTMLDocument(...);
• document.importNode(...)
• document patched by Devtools.
• etc...

In the implementation, we are wondering if this property shouldn't be instead be part of the window object instead, because the right LocalDomWindow is associated with all of those already.
+CC @antosart

What is the semantic of the credentials attribute? credentials=omit vs credentials=present doesn't look good because of inconsistency (omit is a verb, while present is an adjective). In case, I'd suggest having credentials=use instead.

However, I am a bit unhappy with credentials=omit since this is misleading. Credentials are partitioned, not omitted. Moreover, I don't see the point of having a non-boolean attribute for something that can only be set and not unset (credentials=use - if we go with it - has no point of existing, apart from giving a value to be returned by the getter, since a subframe of an anonymous iframe is always anonymous and this cannot be overwritten).

I would reconsider having a boolean attribute instead, something like <iframe anonymous> or <iframe partitioned> or <iframe isolated> or <iframe partitioned-storage> or <iframe clean-credentials> (I fear none of these is a particularly good choice though).

In particular, it informs the COOP page that a cross-origin window tried to access a particular property on its window, and it add information about the cross-origin URL (referrer URL or initial navigation URL).

This seems really bad and not something we should be offering. There's no way to get that URL today.

It seems somewhat "reasonable" for a user to expect they are not being phished if autocomplete works for the login in the third party context. So that might have to be explicitly disabled along with warnings.