Skip to content

Merging requests to the buyer trusted server when several component sellers are involved #1414

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Cyril-CdV opened this issue Mar 21, 2025 · 1 comment

Comments

@Cyril-CdV
Copy link

Context

A desirable property of the request performed to the buyer trusted server is to be common between component sellers involved in the same component auction. When scaling to n component sellers, it reduces an important part of the processing cost of each Interest Group by a factor n, hence minimizing end-to-end latency and server cost. This processing cost includes network latency between the user browser and the buyer trusted server as well as processing in the buyer trusted server.

This nice property is not any more valid when adding query parameters whose values are specific to the component seller: experimentGroupId and slotSize. Seeking feedback on propagating contextual signals to TEE KV server #72 is proposing to add contextual information which will also be specific to the component seller.

We think that increased end-to-end latency and potential infracost of running the buyer trusted server in a TEE are two main critical topics when running the Protected Audience client-side, which could worsen when the number of component sellers per auction increases if this nice property is not preserved.

Proposal

Parameters of the request to the buyer trusted server whose values are specific to the component sellers could be merged in a single parameter, inputsPerSeller, which value would be a JSON stringified object. This object would have the sellers of the component auctions involving the buyer as keys. The value for each of this key would be an object listing the parameters specific to the component seller as JSON key-value pairs.

{
  "component-auction-1-seller": {
    "experimentGroupId": 748,
    "slotSize": "100,200"
  },
  "component-auction-2-seller": {
    "experimentGroupId": 978,
    "perBuyerTKVSignals": "signals-from-component-seller-2"
  }
}

This new parameter would be available as a whole when processing each Interest Group in the buyer trusted server so that the buyer can sent back a single trustedBiddingSignals per received trustedBiddingSignalsKey, whatever the number of component sellers. It will be up to the buyer to manage the business logic related to values specific to component seller, by for instance extracting component-seller specific information from the trustedBiddingSignals in its generateBid() function using browserSignals.seller.

@ccharnay67
Copy link

ccharnay67 commented Apr 7, 2025

Hello,

Additionally to this, can you confirm that, at the moment, if there are multiple component sellers for whom the call to the buyer trusted KV server is done with the same URL, this will still result in two separate calls?

This is what we observe when testing, and would like to confirm if this is the expected behaviour in Chrome? It makes it heavier for buyers in terms of infra cost, since the answer of the KV server in this case will be the same. And since both requests at the same time, we would not be able to benefit from HTTP caching.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants