Providing global configuration for AdTechs

[ningwangpanda]

Current Implementation

Buyers specify and store aggregationCoordinatorOrigin in each interest group when they join or update interest groups. This aggregationCoordinatorOrigin is the choice of the coordinator origin for the buyer’s reports.

const interestGroup = {
...
'privateAggregationConfig': {
'aggregationCoordinatorOrigin': 'https://coordinator.example'
}
};

Sellers specify and store aggregationCoordinatorOrigin in auctionConfig when they call runAdAuction(). This aggregationCoordinatorOrigin is the choice of the coordinator origin for the seller's reports.

const myAuctionConfig = {
...
'privateAggregationConfig': {
'aggregationCoordinatorOrigin': 'https://coordinator.example'
}
};
const auctionResultPromise = navigator.runAdAuction(myAuctionConfig);

During the auction process, buyers and sellers can call privateAggregation.contributeToHistogram() or privateAggregation.contributeToHistogramOnEvent() to make histogram contributions. Specifically, buyers can make histogram contributions from generateBid() and reportWin(); sellers can make histogram contributions from scoreAd() and reportResult().

After the end of the auction (plus a randomized delay), the histogram contributions are bundled together into reports. Chrome fetches keys from the specified coordinator origins (although note that Chrome has caching) to encrypt the reports. Chrome then sends the encrypted reports to buyers and sellers.

Later, when buyers and sellers send the encrypted reports to the Aggregation Service, Chrome fetches keys from the specified coordinator origins to decrypt the reports. Note that the coordinator origin being used for encryption is the one specified when the interest group was joined or updated, and the decryption keys will not be available if the Aggregation Service is being run on or migrated to a different cloud.

Concerns

Our DSPs are above the 10MB limit on kInterestGroupStorageMaxStoragePerOwner. Specifying aggregationCoordinatorOrigin in each interest group increases interest group sizes even further. Our DSPs would like to reduce interest group sizes.

Our DSPs need to repeatedly specify the same aggregationCoordinatorOrigin in each interest group covering multiple endpoints.

Proposals

We propose that Chrome provides global default configuration per AdTech, so that buyers or sellers do not have to repeatedly specify the same aggregationCoordinatorOrigin in each interest group or auctionConfig.

We propose that Chrome provides global configuration at the origin level. Per-site configuration may not provide enough granularity for AdTechs, for example, interest group owners are at the origin level. Some AdTechs may share the same site or even origin. For example, if two DSPs share the same origin and use both AWS and GCP coordinators, DSPs can consider default to the more commonly used coordinator and specify the other coordinator when joining or updating interest groups. Or these two DSPs can consider splitting at the origin level.

This proposal should not raise any privacy concerns. In the current implementation, aggregationCoordinatorOrigin defaults to the AWS coordinator origin for all AdTechs. There are only two versions of coordinators, i.e., AWS and GCP, at this moment, thus this proposal allows AdTechs to default to the GCP version. We only propose that Chrome allows each AdTech to specify the default coordinator origin for itself. The actual keys used for encryption and decryption are still secure as before.

Note that we are not proposing to remove the ability to set aggregationCoordinatorOrigin in interest groups. This feature is still useful. For example, when DSPs migrate from one coordinator to the other coordinator, interest groups can have both coordinators. In this case, Chrome sends two reports, i.e., one for each coordinator. DSPs can compare these two reports during the migration.

In the short term, our DSPs can specify aggregationCoordinatorOrigin in interest groups. However, we would like Chrome to be able to support global configuration per origin before 3PCD so that our DSPs can reduce interest group sizes before 3PCD.

Other Use Cases

Global configuration could potentially be useful for a few different things, for example, specifying contribution limits per AdTech: https://github.com/patcg-individual-drafts/private-aggregation-api/issues/81#issuecomment-2091524214.

[alexmturner]

Hi Ning,

Thanks for the feedback! I hear you that it's not ideal that we have to store the full coordinator origin for each interest group when they will often all be the same for the same ad tech.

Agreed that a global config does seem like a promising approach, especially given that it might be helpful for other use cases too. One challenge there is ensuring that each client receives the same configuration so that this configuration doesn't itself leak any additional information. We'd also need to be careful in the case that a client is missing a configuration. This doesn't seem insurmountable, but might complicate the implementation.

Another option could be to investigate compressing the coordinator representation so that the size impact is lessened. For example, if we were able to use an enum, that might shrink the overhead to ~1 byte per IG. Would that be a suitable mitigation?

We'd also be interested to hear if any other partners have the same concern.

[ningwangpanda]

Our DSPs would be happy to specify aggregationCoordinatorOrigin as an enum as a short-term mitigation.

1. This shrinks the overhead per interest group.
2. Chrome does not expose the actual coordinator origins publicly. This makes the configuration more leak-proof.
3. Should Chrome decide to update the coordinator origins within the same cloud platform, the migration will be transparent to AdTechs. In the current implementation, AdTechs have to point to the new coordinator origins.
4. AdTechs can continue specifying aggregationCoordinatorOrigin as an enum in global configuration once Chrome provides it.