Just to clarify (based on feedback from the 3/6 meeting), the cookie requirement we have on the API right now is intentional to ensure that the debug reports are not leaking more than what a corresponding third party cookie would leak. A durable debugging solution post-3p cookie deprecation would satisfy the overall privacy requirements of the API.

To support debugging after third-party cookie deprecation when the transitional debugging reports are no longer available, we propose a mechanism to leverage the existing aggregate measurement system to send new debugging reports to ad-techs that will require aggregation + noise to be visible to the ad-techs.

The goal is to allow ad-techs to measure counts of various debug events post third-party cookie deprecation and to determine what auxiliary information can be associated with the counts.

In this proposal, we bound the L1 norm of the debugging values, i.e. the sum of the debugging contributions across all debug events in a privacy scope (e.g. per source or per reporting origin within a time window) in a similar way we bound the normal histogram contributions. L1 will be set to 65536 to align with the normal aggregate reporting.

The source and trigger registration JSONs are augmented with two optional fields:

{
  …

  // 128-bit key piece which will be OR'd with the debug report generated by the browser.
  "debug_key_piece": "0xFFF1",
  "debug_value": 128,
}

An aggregatable debug report will be sent when a reportable debug event occurs if both debug_key_piece and debug_value are set in the source or trigger registration for the debug event.

The browser will reserve the least significant 12 bits in the aggregation key to represent the debug code, for example:

Each aggregatable debug report will contain a single contribution of:

key: source debug_key_piece | trigger debug_key_piece (0x0for source error) | debug code key piece
value: debug_value (the value specified at the time the debug report was generated)

The aggregatable debug report will match the regular aggregatable reports policy, but will be sent to a different endpoint .well-known/attribution-reporting/debug/aggregate.

Following up on aggregate debug reporting proposal. We consider allowing developers to opt-in to a subset of debug events via filters. To achieve maximum privacy and security protection, we propose that the browser unconditionally sends an aggregatable report for every source or trigger registration that opts in to aggregate debug reporting. A null report will be sent in the case that there’s no real debug report created. This also allows the browser to send these reports instantly without delay.

The ad-tech may expect to receive a large number of total reports. Given that the default true rate for debug reports (when ad-tech opts-in to all supported debug events) is high, the relative increase from the null reports rate should not be that significant. However, the relative increase in total reports from the null report rate would have more significant impact in the case that the ad-tech only opts-in to debug events that occur infrequently. If there is a concern with a large number of reports, the ad-tech may consider opting-in aggregate debug reporting with sampling on a per advertiser basis for debugging and monitoring.

We appreciate feedback on this proposal regarding the null report rate and its impact on ad-tech use cases and API utility.