Please no further same-origin policy exceptions

[annevk]

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.

[ParisMeuleman]

Even with safe-urls-for-reporting ? My understanding is that we'd only send URLs that the server would've already access to.

[annevk]

So A popups B and B navigates to C. A and C both want reporting and use each others WindowProxy. What gets reported? (Let's assume they're all different sites.)

[ParisMeuleman]

If I'm reading this correctly both would use B's URL, with A reporting the initial URL used for the popup, and C the referrer.
I'm wondering if we should have the empty url instead to avoid misleading logs?

[annevk]

Note that selectively clearing might leak other things, such as B having navigated to C.

Another interesting scenario is then navigating A to D and having C access D. I guess D would get A unless C caused the navigation? (In case C caused the navigation I think both D and C will have an opener. Ideally if D then navigates to E it's identical to B navigating to C.)

I think it would be ideal to have consistent properties we feel safe in exposing, rather than making them conditional. E.g., always including the referrer (and call it referrer) seems reasonable and possibly more informative too.

[camillelamy]

I had in mind that we should clear the referrer URL at least if we navigate cross-origin. So C would see an empty URL in the reports. On the other hand, we probably shouldn't clear the initial navigation URL of the popup opened. So A would still see B.

Coming to consistent properties, IMO the initial URL of a newly opened window works and that is how I more or less envisioned it. However, I am not sure about the referrer. Like I mentioned above if the popup navigates cross-origin, should it have access to the referrer of its first navigation? I am not sure.

Other option, since we are only doing this reporting for report-only mode, where the windows can actually be accessed, maybe we can report the result of what executing window.location on the other window would return? Since the document would have access to it anyway...

[annevk]

The getter throws in all cross-origin cases. I guess that's fair for same-origin cases though, but you might still want referrer then as a separate field.

[camillelamy]

Ok so if we want to have more fields that are always set, we could have the following (provided we have more types of reports):

• navigation to document

1. URL if both documents are same origin including redirects, otherwise empty
2. Referrer

• navigation away from document

1. URL if both documents are same origin, including redirects, otherwise empty
2. Initial navigation URL if the COOP document is same-origin with the navigation initiator, otherwise empty

• access to document from opener

1. URL if both documents are same origin including redirects, otherwise empty
2. Referrer

• access from document to opener

1. URL if both documents are same origin including redirects, otherwise empty
2. Referrer

• access to document from openee

1. URL if both documents are same origin including redirects, otherwise empty
2. Initial URL provided to window.open

• access from document to openee

1. URL if both documents are same origin including redirects, otherwise empty
2. Initial URL provided to window.open

• access between the document and another window which is neither the opener nor an openee (not completely sure it can happen in practice)

1. URL if both documents are same origin including redirects, otherwise empty

Do you think that it is better?

[annevk]

Filed #12 on redirects. I think that might take away some of the complexity here.

I'm having a hard time keeping all the popup scenarios straight. Is this only about access or also about creating them?

And it's possible to access other windows through named targeting (unfortunately that's also an area of interoperability issues and imprecise language, see whatwg/html#313).

Overall though it looks fairly reasonable, but I'm a little worried about leaking non-referrer URLs (even same-origin) in enforcement scenarios as that's one of the things that would no longer leak. It seems fine to leak it in report-only mode though.

[camillelamy]

For the popup case, you first have a navigation* report when you initially navigate to something that triggers/would trigger the bcg switch. This happens in enforcement and report-only mode. Also, the page creating the popup only gets a report if the opener frame is same-origin with the top-level frame.

Then, in report-only mode, you might get the access* reports.

[camillelamy]

Note that I have updated the explainer with the reports as explained above,