Re: [proposals] Expansion on Delegation and Privacy Budget Tradeoffs (#8)

Hey @notImposterSyndromeIfImposter , here's a hypothetical example:

- Advertiser A works with two third parties to measure their ad performance T1 and T2, this is because A is non-technical and could never possibly learn how to use all the complicated new APIs we are building.
- In this simple example, we can assume T2 is set up to "double check" the work of T1 and make sure that T1 is not providing  wrong information to A.
- This means that T1 and T2 both want to use some hypothetical measurement API to measure the same thing, say "conversion counts per campaign"

## Case 1: Delegation easy, privacy budgets independent

This is the most like the status quo. It is easy to delegate all use of the API to both T1 and T2, similar to how cookies work today. Due to the independent budgets, both T1 and T2 can measure what they want independently, and share it with A. However this comes with a risk of an averaging attack, where conversion counts are provided with reduced variance (assume noise was added to protect privacy).

## Case 2: Delegation easy, privacy budgets shared

There are a few sub-options in this case, but in general what happens here is that T1 and T2 have to figure out some way to _share_ a scarce resource. This involves coordination (either with each other or also with A / the publisher), and might be subject to abuse (T1 steals all the budget before T2 can invoke the API, etc).

Careful API design might facilitate this resource sharing and make it more ergonomic, but sharing will be necessary. As the number of measuring parties increases, the accuracy of any one of the parties will decrease as their budget shrinks.

## Case 3: Delegation hard

In this case we can imagine something like PCM which makes it very difficult to delegate work to third parties at all given issues like this one: https://github.com/privacycg/private-click-measurement/issues/57). In this case it is easy to see how some of the issues in (1) and (2) kind of just go away.

Additionally, even just reducing the number of parties that can observe measurement independently relieves some of the issues in (1).  For an example of this see [these limits](https://github.com/WICG/conversion-measurement-api/blob/main/EVENT.md#reporting-origin-limits) in ARA.

However, with tight restrictions on delegation, A may now not be able to fulfill their desired use-case of using a third party, or using two in this double-checking scheme (and there are plenty of other use-cases for wanting to work with multiple third parties). This presents very real problems with adoption and usability of the API.

-- 
GitHub Notification of comment by csharrison
Please view or discuss this issue at https://github.com/patcg/proposals/issues/8#issuecomment-1035035636 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 10 February 2022 15:12:10 UTC