Expansion on Delegation and Privacy Budget Tradeoffs

[notImposterSyndromeIfImposter]

First, thank you to all the presenters; I really appreciate the time and effort you put into not only presenting your point of view but helping frame the various pieces of the puzzle and for providing frameworks to think through these issues.

There were a number of tradeoffs discussed. Most are clear to me and I can articulate the issues and think of clear examples. The one that is hard for me to articulate is the privacy budget tradeoff as a function of delegation becoming easier or harder. Would it be possible to provide a clear example of how making delegation easier or harder impacts privacy budget considerations? I know this was spoken to but I'd really like to have a firmer understanding.

[csharrison]

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 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.

[alextcone]

One small request re:

this is because A is non-technical and could never possibly learn how to use all the complicated new APIs we are building.

Businesses and teams that hire service providers may in fact be very technical. But their focus may be on other business matters. A retailer for example may have a fabulous engineering team. That team, however, is likely focused on the retail site/app. Outside of the ads us case you may recall that most of us rely on infrastructure built by others even though we would be technically capable of rolling our own.

We have to assume that modern economies will produce specializations and service providers to meet needs that fall outside of specializations. Limiting our thinking to "we have to support such and such because there are non technical people" makes us sound a bit out of touch with the broader realities around us.

Otherwise, excellent write up, @csharrison.

[csharrison]

I agree with everything you said @alextcone. However, I also want to make sure we do keep in mind less technical parties in our API designs, because they do exist and their existence may constrain what API decisions we can make.

For instance, imagine an API to delegate to third parties which involves the advertiser site setting a brand new header. Something that seems simple in the API spec is possibly a huge hurdle for a less technical advertiser and has adoption risks. Same kind of situation if publishers had to set this header.

[alextcone]

Agree, @csharrison. I should have been a bit clearer that I think what you are highlighting is as real as what I am adding.

However, a lot of underlying web infrastructure is complex and requires specialization. I actually think that’s ok. If the complex system is supporting a real need you can believe the market will see opportunity and create service and product around it. We should try to be elegant and usable, but be careful that doing so doesn’t just concentrate all of the complexity-reducing service into a few consolidated providers. I acknowledge achieving this nirvana is not scientific and will not be as pure as any different interest would like it to be.

Carry on!

[notImposterSyndromeIfImposter]

Thank you both for the expansion and discussion. Exactly what I was looking for.

[bmayd]

@csharrison Is the question of delegation to multiple 3rd parties taken up anywhere in the current proposal or issues? I didn't find any mentions.

[csharrison]

Hey @bmayd, we don't discuss this in a lot of philosophical detail, but there are a few key points in our explainer:

1. We allow third parties to register events and receive reports in the first place. The "reporting origin" is allowed to be a party that is not the top level site (publisher, advertiser)
2. For event registration, we allow parties that are not directly present on the page to register their own events via HTTP redirects (link).
3. We chose in the most recent proposal revision to give third parties independent privacy budgets (link), and some discussion on the security issue here.