Consider finer-grained destination limits that can operate across reporting origins

[csharrison]

Right now we have some limits which prevent reporting origins from colluding to leak more combined data, but none of them explicitly target the browsing history reconstruction attack.

To that end, we should consider some mitigations in the form of new rate limits. One proposal here is to add the following limits:

1. X unique destinations per (source site, m minutes)
2. Y < X unique destinations per (source site, reporting origin, m minutes). This backstop limit prevents one origin from using up the entire (1) budget.

As with all of our rate limits that operate across reporting origins, same origin policy and our principle of reporting origin control are traded off for privacy. These limits will make it difficult for a set of reporting origins to collude to "query" a large domain of possible sites to see if the user will ever visit them.

[csharrison]

We discussed this issue in the May 1 meeting (link)

One thing that came up was auto-refreshing ads which cycle through creatives in the same slot. We should watch out for this when setting limits.