LGTM3. That said, we really need to stop renaming things that we've shipped. I think there's reasonable justification for doing so in this case, and given Mozilla's support for the `Reporting-Endpoints` model (and lack of support for the `Report-To` model), it seems reasonable to me to follow through with an eventual deprecation. But more generally, shipping creates some unavoidable ossification. I might be over-reacting a bit to a few intents I'm recalling, but I think we need to carefully consider the cost of renaming vs the cost of asking developers to internalize a shift in behavior.
What's the long-term plan for `Report-To`? Do you have a deprecation path you think is feasible, or are we going to end up trying to align it to `Reporting-Endpoints` as an alias at some point in the future? -mike On Thu, Sep 9, 2021 at 5:06 PM Daniel Bratell <[email protected]> wrote: > LGTM2 > > /Daniel > On 2021-09-07 16:06, Ian Clelland wrote: > > > > 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 emails [email protected] >>>>> >>>>> 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 >>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork%3EReportingAndNEL> >>>>> >>>>> TAG review https://github.com/w3ctag/design-reviews/issues/585 >>>>> >>>>> TAG review status Issues 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 name DocumentReporting >>>>> >>>>> Requires code in //chrome? False >>>>> >>>>> 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 >>>>> >>>>> Links to previous Intent discussions Intent 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK_TSXJEfFNfAyon74kke2wbeSmQzuW0KJEYuaZ6av5gWz8YtQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > -- > 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/355976b3-b5cb-2d9b-e738-77e460146b83%40gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/355976b3-b5cb-2d9b-e738-77e460146b83%40gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAKXHy%3DeFn0A6QV%2BbC-z_V%2BBremQpAeba9iYoymWNXi%2BNVbNXHQ%40mail.gmail.com.
