Intent to Prototype: Reporting API: Isolate reports per-document and support the Reporting-Endpoints header

39 views
Skip to first unread message

Ian Clelland

unread,
Dec 11, 2020, 2:15:10 PM12/11/20
to blink-dev

Contact emails

icle...@chromium.org

Explainer


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>ReportingAndNEL

Motivation

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/158

TAG review

https://github.com/w3ctag/design-reviews/issues/585

TAG review status

Pending

Risks



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.



Is this feature fully tested by web-platform-tests?

Not yet, but it will be.

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1062359

Launch bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1156814

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5712172409683968

This intent message was generated by Chrome Platform Status.
Reply all
Reply to author
Forward
0 new messages