Hey Yoav, Thanks for linking me in, I'm happy to provide my feedback here.
Transparency: I'm Scott Helme, the founder of Report URI <https://report-uri.com/>, which is a commercial service for allowing websites to collect reports sent via the Reporting API. We have a pretty strong position on the privacy concerns of websites collecting reports and outline all of the efforts we take to mitigate those concerns in our documentation. The change proposed here seems like a step in the right direction and as, I believe, the largest service of our kind in the world, we would like to show our support. The interoperability and compatibility section states that "no collectors should have been relying on this behaviour" and I can indeed confirm that we don't rely on this behaviour and also agree that no other collector should rely on this behaviour either. The only concern I have is the idea of introducing another way to configure the reporting endpoint for NEL and eventually deprecating Report-To. Unless there's a particularly good reason for doing so, I'd like to avoid the confusion and added work for existing users of the Report-To header to have to make another change. It would be more convenient for sites currently using Report-To to continue to do so for NEL and document based reports, only making the change to add Reporting-Endpoints if they wish to do so. Is there an intended benefit of eventually deprecating Report-To in favour of yet another header? Kind regards, Scott. On Friday, 3 September 2021 at 10:12:01 UTC+1 Yoav Weiss wrote: > *LGTM1* > > Thanks for working on this. IIUC, the motivation for this change is > feedback from other vendors to enable non-persistent document-level > reporting. > I'm glad to see that reflected in Mozilla's position. > > > On Thursday, September 2, 2021 at 8:21:50 PM UTC+2 [email protected] > wrote: > >> 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) >> > > Link? > >> >> Web developers: No signals >> > > FWIW, I'm trying my luck > <https://twitter.com/yoavweiss/status/1433718028563271682>. > > >> 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/7115db05-db5e-4493-b229-996b010bff9fn%40chromium.org.
