Skip to content

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

Open
@Cyril-CdV

Description

@Cyril-CdV

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions