In which version will this ship? Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com | 816-678-7195 *If an API's not documented it doesn't exist.*
On Thu, Sep 9, 2021 at 12:05 PM Mike West <mk...@chromium.org> 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. > > 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 <bratel...@gmail.com> wrote: > >> LGTM2 >> >> /Daniel >> On 2021-09-07 16:06, Ian Clelland wrote: >> >> >> >> On Mon., Sep. 6, 2021, 3:19 a.m. Yoav Weiss, <yoavwe...@google.com> >> wrote: >> >>> >>> >>> On Fri, Sep 3, 2021 at 12:31 PM Scott Helme <scott.he...@gmail.com> >>> 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 >>>>> icle...@chromium.org wrote: >>>>> >>>>>> Contact emails icle...@chromium.org >>>>>> >>>>>> 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 blink-dev+unsubscr...@chromium.org. >> 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 blink-dev+unsubscr...@chromium.org. >> 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 blink-dev+unsubscr...@chromium.org. > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DeFn0A6QV%2BbC-z_V%2BBremQpAeba9iYoymWNXi%2BNVbNXHQ%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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJUhtG_JZY_x9mhh_E8iBb8k40zuaiUNB_4wjd6FH_C%2BsAb6hg%40mail.gmail.com.
