[COOP Reporting] Add some details on which WindowProxy accesses are blocked

[domenic]

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.

[camillelamy]

Thanks! I have updated the explainer. Now it's clear that we only look at get and set.

In terms of types of properties, when both pages are cross-origin, we only send reports for cross-origin properties. Otherwise, we send report for everything. The goal is to determine what breaks/would break so anything that would normally go through should be reported I think.

[annevk]

If you only deal with [[Get]] and [[Set]], there will be several ways to invoke things that will not be logged. I guess that's okay, but it might be tricky for complex applications?

cc @arturjanc

[camillelamy]

I think we can try with only [[Get]] and [[Set]] at the beginning, and if we find cases that are really problematic and not handled by the reporting API, we can extend the reporting API.

[arturjanc]

Yeah, I think we should be pragmatic and start with the operations and properties that we see commonly used cross-origin in interactions between top-level windows; especially because IIUC a more general approach covering all ways to access such properties gets more complex and runs into performance issues.

I expect that data from initial rollouts in report-only and enforcing mode can uncover any blind spots in this design.