Still LGTM On Tue, Sep 21, 2021 at 10:48 PM Ian Clelland <[email protected]> wrote:
> In an exciting last minute turn of events, I've made progress on fixing > one of the last outstanding bugs regarding our implementation of the new > Reporting API spec, and I'd like to amend this intent to include that > change, but I think I might need API owners to take another look at it. > > The original Reporting API specified that credentials should always be > sent with the HTTP POST to reporting endpoints, like other requests. Chrome > never implemented this, and until now, has never sent credentials with > reports. > > This behaviour was changed with the new Reporting API, and the eventual > outcome of https://github.com/w3c/reporting/issues/161 was that the spec > restricted credentials to same-origin report uploads. > > Fixing https://crbug.com/1163645 now means that Chrome can send > credentials with the reports, if and only if the reporting endpoint is > same-origin with the document which generated the reports. I'd like to add > that change to our initial release of the new header. > > To avoid introducing any backwards compatibility issues, and to try to > avoid any unintended consequences of enabling credentials for existing > deployments, I'd restrict this to only apply to the new Reporting-Endpoints > header, and not to the older Report-To header. No existing behaviour should > be changing as a result of this. > > I'd normally consider this a bug fix which aligns the initial release with > the spec, but since it is an expansion of the scope of this intent, and > since any mention of credentials should at least get the attention of > privacy folks, I think this warrants getting folks to take a look again. > > Thanks, > Ian > > > On Mon, Sep 20, 2021 at 1:30 PM Ian Clelland <[email protected]> > wrote: > >> >> >> 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/CAL5BFfV5g3qF9x2aUYEuheygZS-YepsWDcgRGtU%3Dwd%3DbKo6AXw%40mail.gmail.com.
