Intent to Prototype: Reporting API: Isolate reports per-document and support the Reporting-Endpoints header
Ian Clelland
Contact emails
icle...@chromium.orgExplainer
https://github.com/w3c/reporting/blob/master/EXPLAINER.md
Specification
https://w3c.github.io/reporting/Summary
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.
Blink component
Internals>Network>ReportingAndNELMotivation
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.
Initial public proposal
https://github.com/w3c/reporting/issues/158TAG review
https://github.com/w3ctag/design-reviews/issues/585TAG review status
PendingRisks
Interoperability and Compatibility
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.
Gecko: Positive (https://mozilla.github.io/standards-positions/#reporting) Also see https://github.com/mozilla/standards-positions/issues/104 which mentions the current changes.
WebKit: No signal
Web developers: No signals
Ergonomics
The Reporting API is designed to be used in tandem with other features which generate reports.
Activation
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.
Security
No additional security risks associated with the new header.
Debuggability
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.