Splits the reporting cache into a per-document cache for document-generated reports, and the existing cache for network reports. There is currently a single reporting cache per profile, which means that reports from unrelated documents can potentially be sent in a single request. This also introduces the Reporting-Endpoints HTTP response header for non-persistent configuration of document-generated reports.
In order to mitigate privacy concerns with the Reporting API, several changes have been made to the spec: Per-document reports (such as policy violation reports or deprecation repots) have been separated from network reports (such as network error logging) and should be cached separately. This avoids an issue where reports from unrelated documents could be sent together, potentially allowing a users actions on separate sites to be correlated. To avoid creating a persistent cookie or tracking identifier for per-document reports, the existing persistent Report-To header is being replaced with a new Reporting-Endpoints header, which affects only the document it is returned with.
For isolation, risks are low, as there has never been a guarantee of any reports being combined; reports could always have been delivered to endpoints one-at-a-time, and no collectors should have been relying on this behaviour. It is possible that some parties may have been taking advantage of the fact that reports from unrelated windows could be delivered together, but eliminating that is exactly the point of this change.
The Reporting API is designed to be used in tandem with other features which generate reports.
There should be no activation risks at all associated with the improved report isolation. The biggest issue will likely be the potential for confusion between the old Report-To header and the new Reporting-Endpoints header. Either header can be used to configure document-based reports (for compatibility), but only Report-To can configure the endpoint groups for Network Error Logging. Once that API has a new configuration mechanism, we will be able to deprecate the Report-To header completely.
No additional security risks associated with the new header.
Isolating reports from different documents may enable better debugging support from DevTools; currently reports are all sent out-of-band, and combined with reports from other documents, and so cannot easily be seen in DevTools; the netlog viewer is the only access developers have to that traffic. Separate work is ongoing to improve the debuggability of the reporting header syntax and endpoint connectivity issues; that is not covered by this intent.