Clarifications on the Bidding & Auction Services API semantics

[kevinkiklee]

From fledge-docs created by suprajasekhar: privacysandbox/protected-auction-services-docs#10

Thank you for publishing the Bidding and Auction Services API proposal. We have summarized a couple of clarifications we are seeking below. Appreciate your inputs.

Bidding API Semantics

• BuyerFrontEnd service returns a single AdWithBid. However, a buyer might wish to return multiple bids (for instance, one per each custom audience) since some of their bids may be filtered by the seller's auction due to policy and publisher controls enforcements. Would it be possible to add support for returning multiple bids from the BuyerFrontEnd?

• CustomAudienceForBidding includes a priority. Who and how will the priority of custom audiences be taken into account?

• In order to support bids for ads composed of multiple pieces, should the AdWithBid include URLs of ad components as well (in addition to the ad_render_url)?

• Is a buyer’s enrollment ID with Privacy Sandbox the same as the interest group owner origin in the Chrome’s FLEDGE proposal?

Auction API Semantics

• In FLEDGE proposal, the sellers configure AuctionConfig and use it to initiate an auction. However in this proposal, DeviceSignals constructed by the device is included in the AuctionConfig as well. Will it be structurally cleaner to keep the DeviceSignals separate from the AuctionConfig?

Potential Optimizations

The BuyerFrontEnd service sends a GenerateBids request to the bidding service. The bidding service returns ad candidates with bids.

• Is the GenerateBids request executed in a sandbox for a single custom audience or conjointly for all custom audiences originating from a first party advertiser domain? If it is the former, there might be a fixed latency overhead added for every fresh sandbox context as described in Turtledove Issue 304. As we understand it, considering multiple custom audiences from a single domain at the same time, in the same execution context may be compatible with the FLEDGE privacy model.

• In the proposal, the bidding function code is passed to GenerateBids in every request as either js_code or wasm_code. Might it be more efficient to store and precompile the bidding code ahead of time within the bidding service?

While it is great that the proposal is thorough and prescriptive in its API definitions between the client and bidding/auction services, it is not clear what are the incremental changes a buyer or a seller will have to make to their FLEDGE integrations to interact with the proposed bidding and auction services. Would it be possible to summarize the changes required from an ad tech point of view (maybe similar to these)?

[kevinkiklee]

Thanks for the feedback. There is a lot to address in this comment, so I will be calling out the questions we are attempting to address then provide the response:

Bidding API Semantics

Question:
BuyerFrontEnd service returns a single AdWithBid. However, a buyer might wish to return multiple bids (for instance, one per each custom audience) since some of their bids may be filtered by the seller's auction due to policy and publisher controls enforcements. Would it be possible to add support for returning multiple bids from the BuyerFrontEnd?

Answer:
Yes, BuyerFrontEnd can return multiple ads to SellerFrontend, if there is a use case that needs to be supported. The API has been updated to make AdWithBid a repeated field.
Also note that, BuyerFrontEnd can return multiple ads to SellerFrontend. These ads may ultimately be sent to the user's device in SelectWinningAdResponse for joining K-Anonymity sets. The details will be covered in a follow up explainer.

Question:
CustomAudienceForBidding includes a priority. Who and how will the priority of custom audiences be taken into account?

Answer:
Currently we don’t have a concrete implementation for priority. Can you help us understand what semantics for priority makes the most sense (is it needed, not needed, should it be ad-tech provided definition etc.)

Question:
In order to support bids for ads composed of multiple pieces, should the AdWithBid include URLs of ad components as well (in addition to the ad_render_url)?

Answer:
At this point the API doesn't fully support Ad component features, even though the API has some references to it. However, we are open to the idea of evolving AdWithBid to support additional use cases based on partner feedback.

Question:
Is a buyer’s enrollment ID with Privacy Sandbox the same as the interest group owner origin in the Chrome’s FLEDGE proposal?

Answer:
We updated the comment in the explainer to remove reference to Buyer's enrollment ID.
The Buyer Identifier should be the domain address (ETLD+1) of the global load balancer for the Buyer Frontend Service.

Auction API Semantics

Question:
In FLEDGE proposal, the sellers configure AuctionConfig and use it to initiate an auction. However in this proposal, DeviceSignals constructed by the device is included in the AuctionConfig as well. Will it be structurally cleaner to keep the DeviceSignals separate from the AuctionConfig?

Answer:
We have updated the API to separate DeviceSignals from AuctionConfig. Note that DeviceSignals is a common input for both bidding and auction.

Potential Optimizations

Question:
Is the GenerateBids request executed in a sandbox for a single custom audience or conjointly for all custom audiences originating from a first party advertiser domain? If it is the former, there might be a fixed latency overhead added for every fresh sandbox context as described in Turtledove Issue 304. As we understand it, considering multiple custom audiences from a single domain at the same time, in the same execution context may be compatible with the FLEDGE privacy model.

Answer:
For server side execution, the proposal is to have one Javascript and / or WASM code version per Adtech that can be prefetched by the Frontend Services and periodically updated.

GenerateBids will execute per Custom Audience in a V8 sandbox worker, but the same code will be executed in parallel for all Custom Audiences. A precompiled version of code will be executed for most requests. The Javascript context will not be reinitialized if code is the same for different requests.

However, we don't see an issue with executing multiple Custom Audiences from a single domain in the same execution, if that doesn't have privacy implications and Adtech's GenerateBids code can be updated to take multiple Custom Audiences as an input for server side execution.

Question:
In the proposal, the bidding function code is passed to GenerateBids in every request as either js_code or wasm_code. Might it be more efficient to store and precompile the bidding code ahead of time within the bidding service?

Answer:
Bidding / Auction services do not have outbound network access but can only respond to RPCs from BuyerFrontEnd / SellerFrontEnd for security reasons.

BuyerFrontEnd / SellerFrontEnd would periodically prefetch the code, generate a code_version_id based on fetch unix timestamp and cache the code. The code and code_version_id is always sent in the request to Bidding / Auction services. Note Frontend services to Bidding / Auction services RPC payload would be compressed. The code_version_id is tracked inside the Bidding / Auction services. For new code associated with an updated code_version_id in the request, the code is precompiled and cached. If the code_version_id in the request is the same as the tracked code_version_id, then cached and precompiled code is used for execution. We will explain this in more detail when we publish the System Design Explainer.

We have updated the API to reflect the proposal of handling one version of code per Buyer and Seller.

Question:
While it is great that the proposal is thorough and prescriptive in its API definitions between the client and bidding/auction services, it is not clear what are the incremental changes a buyer or a seller will have to make to their FLEDGE integrations to interact with the proposed bidding and auction services. Would it be possible to summarize the changes required from an ad tech point of view (maybe similar to these)?

Answer:
At this point, we are seeking feedback on the API design. We hope to draft the incremental changes (if any) for Adtechs soon.

[kevinkiklee]

I am closing this since we sought your feedback and incorporated them.