On Mon., Sep. 6, 2021, 3:19 a.m. Yoav Weiss, <[email protected]> wrote:
> > > On Fri, Sep 3, 2021 at 12:31 PM Scott Helme <[email protected]> wrote: > >> 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. >> > That's great to hear, thanks! > >> 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? >> > > Thanks for the feedback, Scott! :) > > I believe the future NEL changes are not part of this intent. > Ian - am I correct? If so, what's the best venue for Scott (and others) to > provide that feedback and be involved in that conversation? > That's correct; this intent is just for providing the new mechanism; we deliberately introduced the new header in order to allow NEL to continue to function in existing deployments. My eventual plan is to remove support for configuring document-centered reports with Report-To, and only then to start the process of transitioning network-centered reports, like NEL, away from header-based configuration (if that turns out to be possible), but that will be a separate process, with its own intents. The Network Reporting spec <https://w3c.github.io/reporting/network-reporting.html> is probably the best forum for talking about how to eventually configure those reports; please file issues here <https://github.com/w3c/reporting/issues> for that. (As an aside, the biggest benefit of switching NEL away from headers, as I see it, is that Report-To is currently a cookie-like mechanism, where headers received with one document will affect the processing of subsequent requests. It's unavoidable, certainly, that *some* state needs to be persistent for NEL to actually function, but it would be better if there were an origin-scoped mechanism, to avoid all of the issues with using headers for this.) Ian > >> >> 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 bug >>>> https://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_TSXJEfFNfAyon74kke2wbeSmQzuW0KJEYuaZ6av5gWz8YtQ%40mail.gmail.com.
