search

WICG / attribution-reporting-api

Attribution Reporting API
https://wicg.github.io/attribution-reporting-api/
Other
347 stars 161 forks source link

Storage limits are inconsistent with Clear-Site-Data integration #1270

Open apasel422 opened 2 months ago

apasel422 commented 2 months ago

Per https://wicg.github.io/attribution-reporting-api/#clear-site-data-integration, the effective owner of a source or a report (event-level or aggregatable) is the reporting origin that registered it, as only the reporting origin can clear it.

But we have privacy-agnostic storage limits for sources, event-level reports, and aggregatable reports that are keyed on the source origin or destination site.

This seems like an inconsistency. I would expect one of the following instead:

  1. Source origins and destination sites are also able to Clear-Site-Data.
  2. The storage limits are keyed by reporting origin instead of source origin or destination site.
johnivdel commented 1 month ago

In reference to (1), the desired behavior is Clear-Site-Data would delete all source and triggers that were registered on that site? I think that's reasonable, although I think it'd be interesting to compare the behavior to CHIPs and 3PC and see how this would differ/align.

(2) also seems reasonable, and also prevents some of the Denial-of-service style attacks that the cross-reporting origin limits introduce. I think a difference here would be that in order for someone to blow up the size attributions datastore, they would just need to continue to embed third parties which register sources; which I believe we don't have any limits on.

Whereas with the current behavior, the user would need to at least navigate to multiple different top-level sites. I think trying to solve this eventually reintroduces some kind of DoS vector, but I think anything scoped to reporting origin is probably more aligned with the other limits we have.