Agenda Request - Baseline Discussion on Third Parties

[AramZS]

Agenda+: What do you want to discuss?

Discussing the following baseline requirements:

• Can multiple third parties measure the same event with no restrictions?
• Can multiple third parties measure the same event with restrictions?
• Can third parties invoke the measurement API?

[AramZS]

Considering what is currently on the agenda, I'll save this for only if we have time at TPAC

[eriktaubeneck]

In advance of the Feb 29th discussion, I wanted to post some thoughts on this subject to seed the discussion. This content is not at all definitive, please follow up in this issue and/or at the meeting with proposed changes, concerns, or any other feedback!

Context

The private measurement APIs discussed by the PATCG all require some type of browser interaction (e.g., calling an API) by the website (either the source site or trigger site.) It is often the case that the website operator will decide to use a third party service provider to perform these interactions on their behalf.

The proposed private measurement APIs all include some form of budgeting or rate limiting to achieve their privacy goals. This presents challenges with respect to third parties.

Goals

We aim to achieve the following in our API designs, but also recognize there are trade offs to consider.

1. Top-level site owners must be able to delegate usage of the measurement API to third party service providers.
2. Top-level site owners should be able to utilize multiple third party service providers.
   a. It may be reasonable to standardize an upper limit on the number of third party service providers.
3. The utilization of multiple third party service providers must not result in a reduction in the privacy afforded by the API.
   a. The utilization (or general support for) multiple third party service providers should not result in a reduction in the utility afforded by the API.
4. The measurement APIs must not require top-level context to operate, e.g., they should be accessible within an iFrame or similarly isolated context.
   a. A site may restrict access to APIs for third party service providers so that only their preferred providers can use the APIs.
5. It must not be possible for one third party service provider to actively degrade or prevent the operation of another third party service provider.
   a. It may be possible for the top-level site to configure a state that degrades or prevents the operation of some third party service providers, e.g., by embedding too many providers.
6. By default, it must be possible for an embedded third party service provider to operate the measurement APIs without requiring the top-level site to take action (beyond embedding the third party service provider.)
   a. It must be possible for sites to override these defaults (see 4a.)
7. Whenever possible, the measurement APIs should utilize reasonable defaults but may allow for more precise configuration.
   a. Sites that rely on defaults should not receive significantly less utility from the API.

Key Issue: Privacy Budget Management

Currently, all the proposed measurement APIs utilize some form of a privacy budget, which determines how differentially private noise is applied to outputs of the API. Utilization of the API deducts from that budget over the course of an epoch, and if fully consumed, the API cannot be used until the next epoch. In order to achieve goal #⁠3, this budget needs to constrain the usage across all third party service providers, which implies that the budget must somehow be allocated between them. This allocation presents a particularly complex set of trade offs between these goals.

For example, if the API allows the budget to be consumed arbitrarily at each invocation, the first invocation may consumer the entire budget, conflicting with goal #⁠5. Conversely, we could require top-level site owners to assign portions of their budget to each third party service provider, however this conflicts with goal #⁠6. We could additionally add a default and assume that most sites will use N third party service providers, and by default assign each with 1/N of the budget (unless otherwise configured.) Deciding on a value for N is non-trivial: too large an N and we conflict with goal #⁠7a; too small and we conflict with goal #⁠2.

[eriktaubeneck]

The original issue also called out two other related items:

1. Can multiple third parties measure the same event with no restrictions?
2. Can multiple third parties measure the same event with restrictions?

From a privacy standpoint, if the budget management issue can be addressed, then there shouldn’t be an issue with measuring events multiple times (within the bounds of the global budget.) From an ad tech perspective, there may be some concerns around one third party service provider not being able to measure an ad in an iFrame placed by a separate third party service provider.

It would be great to hear from others about their concerns on these specific items.

[csharrison]

I think it would be productive to go through the goals and their implications, and see if we can get alignment on them (or a subset of them). There are some very nuanced privacy / utility / security tradeoffs here that you outlined very well. Thanks.

[eriktaubeneck]

I opened a PR with this content (as a draft) so that it's easier for folks to add suggestions.

[martinthomson]

To further the discussion we just had, I think that we should avoid must/should/may here and instead frame things as desirable or not.

A suggestion for the disclaimer:

We understand that some of these goals are in tension. It might be the case that no solution will be able to satisfy all of these goals at the same time. A solution might have to balance concerns or offer sites options that allow them to select how things like privacy budgets are allocated. A final solution can use these goals as a way of describing its capabilities, which might include options for sites to shift any balance to suit their needs.

[AramZS]

(Noting that we will resolve this issue on the associated PR before our next meeting)

[eriktaubeneck]

@martinthomson point taken, and I'm all ears if you have a suggestion for a different modal verb that's easy to swap out.

I did update the text in the PR to replace all but one "must" with "should". (I left a "must" in #1, as I think we have pretty strong consensus that it must be possible to delegate.)

[eriktaubeneck]

@AramZS, can we close this issue, point to the PR, and open a new issue for the next meeting if required?

[AramZS]

This PR should close this issue for now.