Privacy budget with Private Aggregation API

[fhoering]

The private aggregation API explainer defines those notions of privacy budget:

• L1 bound of 2^16 = 65 536 as proposed by the Attribution Reporting API with Aggregatable Reports explainer.

• We initially plan to enforce a per-origin budget that resets daily

Fledge integration of the private aggregation API is mentioned here.

Some questions on the integration with Fledge:

• How will the budget be reset for Fledge ? In this example 1 each display makes a contribution of 1. But with the per origin definitions above it would mean if I display 5 ads to the user per day I would have a contribution of 5. This would greatly reduce the utility of this API depending on which capping parameters are set for the user. It also seems very different from the per source budget in the attribution reporting API.

• example 2 mentions measuring the bid value. However the example only mentions bids of 100 or 200 which would be integers. In reality the bid is a float value and could be up to 6 decimal digits precision (https://developers.google.com/authorized-buyers/rtb/downloads/realtime-bidding-proto.txt). Something realistic for aggregated values would be to measure a least a precision of up to 2 digits and allowing values from 0 to 100, which would mean, when this is encoded in some form, a contribution of up to 10000. So just measuring the bid value would already consume 15% of the budget. How should float values be handled in general ?

• With the L1 bound of 2^16 max 16 536 contributions could be handled. When multiple float values with multiple digit precision must be handled it can quickly reach its limits. Would it be an option to increase the L1 bound to a higher value and in exchange increase the noise ? The budget would stay the same in this case but the seller/buyer could in exchange wait longer to get his report to reduce the signal to noise ratio.

• The absolute value of the measured signals per day are not the same. For example, there might be 1mio losses for 10000 displays for 100 clicks for 1 sale. It means if all that applies to the same budget the losses will exhaust the budget quickly and nothing is left for the clicks. So it seems reasonable to at least separate the budget by event type

[JensenPaul]

@alexmturner @johnivdel

[alexmturner]

Hi Fabian,

So you're aware, we've set up an issue on the Private Aggregation repo to seek feedback on the value and scope of privacy budgeting: patcg-individual-drafts/private-aggregation-api#23. Please also note that we haven't made a decision yet on the L1 bound value, but are using 2^16 for testing.

To answer your questions:

• Under the current design, we set a limit on the contributions for a particular reporting origin over the last ~24 hours (as a rolling window).
• Note that if you're filling in bid values, the final result you obtain would be a sum of those values across the reports (plus noise). So, there will inherently be some lost precision from this aggregation. Still, you're right that this system would cause additional precision loss by rounding to an integer.
• Thanks for the suggestion! I don't think there would be any privacy concerns with this. It also does seem reasonable to have a higher value given that this covers a contributions for a day (compared to one source event in Attribution Reporting). But, I'll need to look into whether there are any implications for the aggregation service.
• We do suggest that developers scale the values they contribute based on expected volume (i.e. not just using a value of 1). So, you could use a smaller value for the more common events to avoid exhausting the budget. Still, I can see how a maximum of 2^16 might not allow this properly; if we increased the budget to allow more granularity, would that resolve this issue for you?

Thanks for the feedback!

[fhoering]

Thanks for the reply.

if we increased the budget to allow more granularity, would that resolve this issue for you?

Let's say we increase it to 300k and I use 100k for bid requests, 100k for displays and 100k for clicks which means I have to scale up displays and clicks. In any case, to reduce noise, one will always be close to the limit by scaling up.
Now, with those 3 types of events, for each type there is actually no capping in place. So if I'm above the 100k for bid requests they will still "eat" up the budget of the others. It means no optimistic handling is possible. I always need to scale for the worst case. So it doesn't seem like an optimal solution.

That's why it seems preferable to have some budget by type of event.

[alexmturner]

Sorry for the delay in responding!

As we discussed in the FLEDGE WICG call, thanks for the feedback that managing contribution budgets could be difficult when you have multiple measurements going on. One concern we have with budgeting different events separately is that different ad techs may want different distributions of their budget amongst the possible events. We have a proposal that might help mitigate this issue: we're considering changing the time scope of the contribution budget to per-10 min instead of per-day (patcg-individual-drafts/private-aggregation-api#23 (comment)).

Further, we floated the idea of revealing the remaining contribution budget (within the FLEDGE worklet), which may help with prioritizing different measurements when the remaining budget is tight. This would need additional thought, but we'd appreciate any feedback on whether this would help alleviate your concern.

Finally, we hope the per-10 min budget change might help mitigate some of the concerns about sufficient granularity. Still, the aggregation and addition of noise do limit the precision available in the final (summary) measurement.