Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
apasel422 opened this issue May 3, 2024 · 1 comment
Open

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

apasel422 opened this issue May 3, 2024 · 1 comment

Comments

@apasel422
Copy link
Collaborator

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
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants