Contact [email protected] Explainerhttps://github.com/w3c/reporting/blob/master/EXPLAINER.md
Specificationhttps://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 componentInternals>Network>ReportingAndNEL <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork%3EReportingAndNEL> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/585 TAG review statusIssues addressed 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 <https://www.chromestatus.com/admin/features/launch/5712172409683968/5?intent=1>) Also see https://github.com/mozilla/standards-positions/issues/104 which mentions the current changes. WebKit: No signal (email thread bumped recently) 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 <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> ?Yes Flag nameDocumentReporting Requires code in //chrome?False Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1062359 Launch bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1156814 Link to entry on the Chrome Platform Status https://www.chromestatus.com/feature/5712172409683968 Links to previous Intent discussionsIntent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/_CIlziJRPME/m/w_4qFmKSAgAJ This intent message was generated by Chrome Platform Status <https://www.chromestatus.com/>. -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK_TSXJf5BbYpnV4YXPZ%3DHY%3Dq-X597Da8x%3DgGF6qiYxCdVWGqQ%40mail.gmail.com.
