On Thu, Sep 9, 2021 at 3:05 PM Mike West <[email protected]> wrote: > 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. >
Agreed -- we certainly thought long and hard about whether we could keep the existing naming; the fundamental problem we ran into was in being able to ship this without breaking NEL, and eventually concluded that since it was impossible to know, with the existing Report-To header whether the intended usage was going to be ephemeral (like the new header) or persistent (like with NEL), that we couldn't change the semantics of Report-To and also keep backwards compatibility. > > 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? > We do want to deprecate it; that needs to happen along two different paths: - We need to remove support for having Report-To configure document reporting; that is, Reporting-Endpoints should be the only mechanism for those reports. - We need to ship a better configuration mechanism for NEL & co., one which is correctly origin-scoped, and does not allow an arbitrary misconfigured document to overwrite the persistent configuration for the rest of the resources at that origin. Most recently, I had proposed using Origin Policy as that mechanism, but the future of that spec is unclear. Once both of those have been done, we will be able to deprecate the Report-To header. > -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/CAK_TSXJu2HDnsM9RuouTwKjG-AQU-iXBnRucMjsV_Axh5n3eHw%40mail.gmail.com.
