Intent to Ship: Reporting API: Isolate reports per-document and support the Reporting-Endpoints header

[Ian Clelland]

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

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) Also see https://github.com/mozilla/standards-positions/issues/104 which mentions the current changes.

WebKit: No signal (email thread bumped recently)

Web developers: No signals

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?

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.

[Yoav Weiss]

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

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) 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. 

[Ian Clelland]

https://lists.webkit.org/pipermail/webkit-dev/2021-September/031978.html (The earlier message was from December, around the time of the I2P, but didn't get any response then)

[Scott Helme]

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, 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.

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?

Kind regards, 

Scott. 

[Yoav Weiss]

On Fri, Sep 3, 2021 at 12:31 PM Scott Helme <scott...@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, 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.

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?

[Ian Clelland]

On Mon., Sep. 6, 2021, 3:19 a.m. Yoav Weiss, <yoav...@google.com> wrote:

On Fri, Sep 3, 2021 at 12:31 PM Scott Helme <scott...@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, 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 is probably the best forum for talking about how to eventually configure those reports; please file issues here 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

[Daniel Bratell]

LGTM2

/Daniel

--
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+...@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.

[Mike West]

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

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.

[Joe Medley]

In which version will this ship?

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

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.

[Ian Clelland]

On Thu, Sep 9, 2021 at 3: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.

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.

[Ian Clelland]

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

[Yoav Weiss]

Still LGTM