w3c / reporting

Reporting API
https://w3c.github.io/reporting/
Other
75 stars 36 forks source link

Batch reports from related documents? #226

Closed clelland closed 2 years ago

clelland commented 3 years ago

Calling out a comment in https://github.com/w3c/reporting/issues/158#issuecomment-525896617: the spec has currently removed all batching of reports from separate documents / workers.

If a single document generates multiple CSP violations, for instance, those can be sent in a single message to the endpoint, but if a document and its dedicated worker, or its same-origin iframe generate those same reports, then they are sent in multiple messages. We could make better use of the network if these reports could be batched together.

Q1: Is this a reasonable optimization to allow browsers to make? Setting the agent cluster as the boundary should mean that there's no unintended information leak across documents, I think. I expect that it could also be entirely optional; batching shouldn't be something that developers rely on, but rather an opportunistic means for the browser to consume less bandwidth when it can.

Q2: Is it worth the additional spec complexity to do this? It would likely involve at least associating the report buffer with the cluster, rather than individual documents, and making sure that the endpoint configuration is separated from the reports themselves. There may be more complexity that I haven't considered though.

ddworken commented 3 years ago

From my experience using the previous version of the reporting API, the batching led to some counter-intuitive and confusing behavior that really threw me for a loop. The issue that I ran into was:

  1. Multiple services were deployed on the same origin
  2. I wanted each service to use COOP reporting but to send reports to different destinations. We used different destinations to allow us to track that a report was associated with a specific service
  3. Each service named the reporting group foo

This meant that if:

  1. Service A triggers a report AND
  2. The user quickly browses to Service B

Then the report for service A could get sent to B's reporting destination (since it is same-origin and has the same group name). This led to us misattributing reports.

The fact that the current version prevents that by only batching reports if they come from the same document would prevent this confusion and is a nice improvement in my opinion. Allowing batching between a document and its same-origin iframe could allow this to happen again.

clelland commented 3 years ago

Thanks for the feedback, @ddworken! That's definitely useful.

You're right that if reports were batched by endpoint name, it could lead to this kind of confusion. It would have to require an exact match on the configured URL.