-
Notifications
You must be signed in to change notification settings - Fork 30
Aggregate Report Accounting Budget Recovery Criteria & Process
This explainer describes the criteria and process that adtechs would use to request aggregatable report accounting budget recovery for failed or misconfigured Aggregation Service jobs.
Establish the criteria and process for aggregatable report accounting budget recovery for Aggregation Service jobs , and get feedback that the team can use to improve the criteria and process over time.
The Aggregation Service budget recovery tool enables adtechs to recover from budget-related failures and errors. This tool allows adtechs to recover from situations where the aggregatable report accounting budget is consumed, but the expected summary report is either not received by the adtech (for example: when there are client-side errors, coordinator service errors etc), or is incorrect/not as expected (for example: in the case where the adtech accidentally misconfigures batches).
The team will be reviewing and approving budget recovery requests using the following criteria:
- 2 recovery requests per adtech per week. Adtechs may batch multiple jobs into one request.
- Max of 1 recovery per shared ID. To preserve privacy, we will allow a maximum of one recovery per shared ID.
- Aggregation Service failures will be exempt from both caps. Failures determined to be caused by issues in the Aggregation or Coordinator services (example: aggregatable report accounting service failures) will be exempt from both caps listed above.
Adtechs may request budget recovery filling out the budget recovery form and providing the information outlined below:
- The result of calling the getJob endpoint for the failed job(s). Adtechs can combine multiple jobs into one request.
- Reason for your request (e.g. Was the job misconfigured? Was there an outage?)
- Are you facing privacy budget errors in a new Aggregation Service deployment? Or is a previously successful deployment now failing?
- What cloud provider are you using (AWS or GCP)?
Once your request has been received, we will assess whether your request meets the criteria described above. If it does, you will be sent additional instructions on retrieving and sharing the shared IDs to complete the process.
Note: The budget recovery request must come from the email that was provided as the point of contact during Aggregation Service onboarding so we can ensure the request is valid.
While the requirement for budget recovery request reason and the limit of 1 recovery per shared ID in this proposal provides some checks and guardrails against privacy loss, there is the risk that a bad actor could request recovery of budget for all their jobs. For users that have 3PCs enabled, this is not a privacy regression since this is already possible with debug reports. For users that do not have 3PCs enabled, there is the risk of a privacy regression since bad actors could reprocess all their reports, circumventing the no duplicates rule, and potentially gaining cross-site information on specific users.
To mitigate the risk of a privacy regression, we plan to have a mechanism to review the percentage of shared IDs recovered by an adtech and suspend recovery if adtechs request recovery beyond a threshold. This mechanism will be available before the new experience for informed user choice is available. In addition, we will be reviewing requests and justifications once we launch the tool to determine how best to support and give guidance to adtechs on possible improvements they can make (for example: guidance on batching strategies to avoid failures).
We plan to explore other mitigations as outlined in future work and will adjust the proposed mitigation in this explainer as needed based on results of the exploration and adtech usage for this feature.
In the future, we propose supporting more automation, validation and transparency to minimize the privacy loss. Examples of improvements we are exploring include:
- Mechanisms and automation for validation of failures that require budget recovery. For example: Aggregation or Coordinator Service failures that result in budget being consumed and a report not being generated.
- A time-based requirement where each request would be limited to jobs within a 24-hour period. This would allow adtechs to recover from failures/outages that may span a whole day and impact all the jobs for that day, but would still provide a guardrail against recovery for all jobs over long periods of time.
- A public ledger on the number of recoveries and justification per adtech for transparency.
We encourage adtechs to review the criteria, test the recovery process when they encounter failures or issues, and provide feedback by responding to this GitHub post. Feedback on the current criteria will help inform and guide improvements in the future.