Measuring interest groups size on device

[ardianp-google]

In the PA-API, there is a 10MB limit for interest group size on devices (as per https://wicg.github.io/turtledove/#max-interest-groups-total-size-per-owner). Currently, ad-tech companies lack visibility into the frequency with which browsers reach this limit, resulting in interest group purging. This information is crucial for understanding the extent to which interest group payload optimization is necessary. We propose that Chrome implement a mechanism to surface this data, maybe along with the distribution of interest group sizes, potentially through the Private Aggregation Reporting API.

Additionally, we have a similar request to expose time-out information via the Private Aggregation API (patcg-individual-drafts/private-aggregation-api#119).

[morlovich]

Hi... So we've been looking to potential ways of addressing feedback given here and in similar issues, and put together a doc with a possible direction:

https://docs.google.com/document/d/1EHVJkKUKIL4dMFrcJ6FJH65Ad4Ml7pKZ8Iepft5OvYk/edit?usp=sharing

we would appreciate feedback on the overall approach, and also on the particularities of metrics and how well they suit their needs (including, of course, potential alternatives you would find preferable). Probably easiest to put it here, since I don't know how to sensibly ACL a public doc so it's accessible to people and not spammers.

[dmdabbs]

Thank you @morlovich. You posted your proposal here and on a private agg repo issue and on both posts suggested commenting here. May I suggest you point folks to comment in one place? It is too bad there's no way to control comment spammers.

[ardianp-google]

Thanks @morlovich. The reserved.once proposal looks good to us.

[rdgordon-index]

I'm curious about the overlap of this proposal for the timeouts/fetch times and the #430 implementation...

[morlovich]

I think the overlap is solely in script execution times, at least for now.
(To the extent one is comparing a proposal and something actually implemented)

[dmdabbs]

Thanks @morlovich. The reserved.once proposal looks good to us.

+1

[morlovich]

FWIW #1272 is the shape it actually seems to be taking in the implementation.

[dmdabbs]

Appreciate the explainer PR. Easier than combing through the reserved.once CLs.

[morlovich]

Just landed experiment config for this for canary/dev 50% (though it will take some time for it to take effect).
Please note that the parsing of new base values is not forward compatible, so you'll want to use try/catch (which you should be using for permission policy anyway).

[morlovich]

Config for beta 50% landed as well. As usual, it takes some time for the config to reach that many people.