Improving support for debugging (without debug mode)

[alexmturner]

Private Aggregation currently supports a temporary debugging mechanism called debug mode to help developers integrate with the API and debug their usage. However, this mechanism is tied to third-party cookie eligibility and will thus be deprecated along with third-party cookies.

We’re exploring ways to continue supporting this use case. In particular, we aim to allow developers to measure the frequency of certain ‘debug events’ and to split these measurements on relevant developer-specified dimensions (e.g. advertiser or code version). We also aim to support these use cases with minimal or no privacy regressions and for this support to be available after third-party cookie deprecation.

Design idea

One possible design is to introduce a new JavaScript call that allows developers to send a contribution if a browser-defined 'debug event' occurs, e.g.:

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

Note that this is conceptually quite similar to the contributeToHistogramOnEvent() method already available as part of the Protected Audience extensions to Private Aggregation.

Debug events

This mechanism could support sending contributions in a range of debug events, e.g. in case of:

• insufficient budget (either 10 min or daily) to send a report
• contributions being dropped due to the per-report limit
• no reporting errors (i.e. a report is successfully scheduled to send)
• a worklet crash

That list is not exhaustive, but it should also be possible to continue to extend the list in future iterations.

Budgeting

To avoid privacy regressions, these contributions would be limited by the usual client-side contribution budget. However, this proposal would require a mechanism to “reserve” some portion of the budget for these debug events. This is necessary to allow for contributions measuring an insufficient-budget event to successfully send.

Aggregating separately

Ad techs may wish to process their debug event histogram contributions separately from other contributions. This would be possible by using a different filtering ID for those contributions. This mechanism would also allow for flexibility in which groups of contributions can be processed together or separately.

Note that this design differs slightly from Attribution Reporting’s earlier aggregate debugging proposal. That proposal sends separate debug and non-debug reports and makes sending a debug report deterministic when debug reporting is enabled. It is difficult to adapt this mechanism to Protected Audience buyers without privacy impacts.

[maplgh]

This is a welcome improvement as it provides some visibility into dropped contributions due to contribution budget and limits.

I can see the following concerns, but I may be missing something, please correct me if I am wrong.

• This feature will eat into the contribution budget and contribution limit, which are metrics they are helping track as it will need to reserve some portion of them.
• The fact that these contributions are included in the regular reports and have to be processed with the other contributions somewhat limiting as a separate cadence may be desired. The alternative to process separately using filter_id is inefficient in terms of Aggregation Service resources as all the reports will have to be reprocessed.

Having separate limits and reports can help address these concerns.

[alexmturner]

Thanks for the feedback! Glad to hear you think it'd be useful. Some thoughts on the concerns you highlighted:

We do plan for these 'debug' contributions to share the existing budget as adding an additional budget would unfortunately impact privacy. And we're hoping to address the contribution limit piece in parallel (as discussed in #81).

You're right that reprocessing the reports would be necessary to process the different contributions at difference cadences. However, separating the debug events into a separate report (with a separate api type or similar) might not help too much as, in that case, instead of reprocessing the same report, you'd be processing (up to) double the number of reports. There's also a concern that this partitioning could amplify a counting attack, especially for Protected Audience bidder reporting.