Enforce contribution budgets at the origin level

[ningwangpanda]

Currently, Chrome enforces contribution budgets (2^16 per 10 min and 2^20 per day) at the site level.

Proposal

We propose that Chrome enforces contribution budgets at the origin level as well. We have multiple AdTechs (i.e., origins) sharing the same site. We would like to enforce contribution budget consumption of each AdTech.

Note that we are proposing enforcement of contribution budgets at BOTH the site and origin levels. We understand that we cannot lift the enforcement at the site level. Otherwise, each site can create an unlimited number of origins to get unlimited contribution budgets.

It would be great if Chrome can support origin-level debugging and monitoring: #131. For example,

privateAggregation.contributeToHistogramOnDebugEvent(
  "insufficient-10min-budget-adtech1", {bucket: 12345n, value: 67n, filteringId: 8n});

Option 1: Percentages (Recommended)

We propose that Chrome allows AdTechs to specify a percentage (from 0 to 100) of the total per-site contribution budgets for each origin. The percentages of all origins under the site do not have to sum to 100. We assume there are 3 AdTechs under the same site (company.com): adtech1.company.com, adtech2.company.com and adtech3.company.com. Suppose the total contribution budgets at the site level is X. Here are several situations.

1. AdTech1: 50, AdTech2: 30, AdTech3: 20. In this case, the percentages sum to 100. AdTech1 reserves 50% * X, AdTech2 reserves 30% * X, AdTech3 reserves 20% * X. There are no spillovers in this situation.
2. AdTech1: 40, AdTech2: 40, AdTech3: 40. In this case, the percentages sum to 120 (> 100). This implies that we allow spillovers, namely, we allow each AdTech to consume up to 40% * X until company.com runs out of X at the site level. AdTechs can leverage spillovers to minimize unused contribution budgets cross origins.
3. AdTech1: 30, AdTech2: 30, AdTech3: 30. In this case, the percentages sum to 90 (< 100). This implies that some contribution budgets are left unused at the site level. This might be less ideal for some AdTechs, but valid use cases for other AdTechs.

We would like to set the default percentage to 0 at the origin level so that new origins won’t interfere with other origins in unexpected ways.

Option 2: Weights

We propose that Chrome allows AdTechs to specify a weight for each origin. To decide the shares of the contribution budgets for each origin, we sum all weights and then divide the weight of each origin by the sum. Unlike Option 1 (the percentage approach), this option requires Chrome to calculate the shares for each origin according to the configurations of all origins. When one origin changes its weight, Chrome needs to recalculate the shares for all origins. We also need Chrome to add a percentage value that applies to all origins to support spillover. Note that with this approach, there is only one spillover value per site.

We assume there are 4 AdTechs under the same site (company.com): adtech1.company.com, adtech2.company.com, adtech3.company.com and adtech4.company.com. Here is an example. AdTech1 weight: 2, AdTech 2 weight: 0, AdTech3 weight:1, AdTech4 weight: 1. The sum is 4. AdTech1 gets 50%, AdTech2 gets 0%, each of AdTech3 and AdTech4 gets 25%. If the spillover value is 10%, AdTech1 may consume up to 60% of the contribution budgets if some contribution budgets are left unused at the site level. Stories for the other 3 AdTechs are similar.

The default weight should be 0 to minimize surprises. For example, origins might be created for testing purposes or accidentally.

Overall, we recommend Option 1 (the percentage approach).

Lastly, both proposals apply to both the per 10 min contribution budgets and the daily contribution budgets.

[alexmturner]

Thanks for your feedback! As discussed in #131, to support aggregate debugging, we'll need a mechanism for reserving some budget for debug events. I'm wondering if we might be able to combine these two proposals into a single generic mechanism.

We could allow a 'budgeting group' to be specified for each contribution, for example:
privateAggregation.contributeToHistogram({bucket: 123n, value: 45, group: 'example'});
Separately, we could specify a budget limit per group. As you note, we'd still need to make sure the site-level limits are never exceeded.

I think this proposal should support your use case -- each ad tech would use a different 'group' (or two to support debugging as well) and the site would divide up their budget to these groups as they deem appropriate.

[ningwangpanda]

Hi @alexmturner, thanks for your reply! The 'group' proposal should be able to support our use cases.

[maplgh]

Thanks @alexmturner, this proposal looks reasonable. Would also like to learn more about the 'mechanism for reserving budget'.

[alexmturner]

@maplgh, just wanted to highlight we've now published an explainer with more details about our proposed mechanism: https://github.com/patcg-individual-drafts/private-aggregation-api/blob/main/named_budgets.md. Please let us know if you have any feedback on it!