privacysandbox / protected-auction-services-docs Goto Github PK

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)?

Could the proposed Bidding and Auction Services API potentially pose the following challenges:

• High adoption and maintenance costs of ad tech arising from the new integrations, disjoint from the existing real-time bidding data flows.

• Increased network bandwidth from the additional data flows introduced between the ad techs, client and the Bidding and Auction Services API.

• Increased end user latency due to the sequential network requests for the execution of the contextual and remarketing auction and bidding functions.

We wonder if this idea of using trusted servers to execute remarketing auction and bidding functions can be better integrated with the existing real-time bidding data flows.

For instance, the traditional ad requests from the client to an exchange and in turn the traditional bid requests from the exchange to bidders could include a user’s private interest group data that is encrypted by the client (such as Chrome browser or Android), such that only the trusted server can decrypt and process such data, along with contextual signals about the current site or app.

The same trust model outlined in FLEDGE services overview could be used to verifiably enforce that the encrypted interest group data can only be used as intended in FLEDGE auctions:

• Only the expected binary version of the FLEDGE auction or bidding services hosted in a secure, hardware-based trusted execution environment (TEE) can decrypt the interest group data with the use of private keys from two key management systems.

• Custom, ad tech provided auction scoring and bidding functions are run inside a sandboxed environment within a TEE to prevent any leakage or reuse of information across individual requests and to ensure the desired restrictions on the allowed data usage and FLEDGE API semantics.
  

Will the Bidding Service worklet execution work as described here w/r/t to the executionModes?

Hey fwends, getting caught up and have a few clarifications and questions:

Seller Ad Service
Trying to understand what restrictions might be envisioned here. I saw "The seller's ad service is the existing stack of the seller that facilitates real-time bidding auctions" so want to dig in on that more:

1. Is that literally the case, that this is existing code on existing servers running in existing datacenters (caveat that code changes to accommodate SellerFrontEnd flow)? Or are there restrictions such as, this is expected to run in the cloud in a Nitro Enclave, or the types of communication out of the server (log processing, requests in hot path to other systems, creative serving)?
2. Would Chrome browser attempt to restrict the request/response structure to/from Seller Ad Service, other than the encrypted Protected Audience Data portion as described here.
3. Would there be any audit expectation?

Event Level Reporting (for now)
I'd like to understand the "for now" part better. Is the expectation that some level of Event Level Reporting will continue just with more restricted data (i.e. no or less Interest Group data, more noise, etc), or that there will be no Event Level Reporting at all? I ask for a few reasons:

1. Sellers and buyers have a strong claim to event level data that exists now that is not specific to the user who the impression was served to, and that data is used for many purposes outside of targeting.
2. Perhaps not the Seller, but the Buyer who is creating and using the Interest Groups has a less-strong-but-still-reasonable claim on wanting to analyze the usefulness of their Interest Groups at a detailed level, and to see "landscape" data showing them how they might adjust their buying structures and settings.
3. Ad Techs, at the least the one I've been working for for 11 years, often need Event Level Data for operational purposes such as debugging.

Also, even in the "for now" times, will SellerFrontEnd and BuyerFrontEnd service be able to log event level data and phone home?

TEEs
I am no security expert, so if there's something very obvious here than apologies, but has any consideration been given to TEEs running in non-public-cloud environments but providing the necessary constraints, attestations, etc, through some combination of technical and audit requirements? I ask because one of the twix-inesses I see here is that Ad Techs (at least one I work for) will likely continue to have to support some set of existing use cases outside of a Fledge/Parakeet context, and those use cases are of size anywhere between non-trivial and quite substantial. Having to setup a TEE inside of a non-public-dc with some set of even relatively "intrusive" requirements could be preferable to forcing network and system topologies.

This was one of my questions originally in issue #29 , but after some internal discussion I wanted to be more specific and dig in on this one in particular.

TEEs
I am no security expert, so if there's something very obvious here than apologies, but has any consideration been given to TEEs running in non-public-cloud environments but providing the necessary constraints, attestations, etc, through some combination of technical and audit requirements? I ask because one of the twix-inesses I see here is that Ad Techs (at least the one I work for) will likely continue to have to support some set of existing use cases outside of a Fledge/Parakeet context, and those use cases are of size anywhere between non-trivial and quite substantial. Having to setup a TEE inside of a non-public-dc with some set of even relatively "intrusive" requirements could be preferable to forcing network and system topologies.

Thanks for the Event Level Reporting explainer!

First thing I notice is that reportResult and reportWin have different signatures than on device. It seems like browserSignals has been removed, and the table indicates that some of the fields have moved to sellerReportingMetadata in reportResult or buyer equivalent for reportWin.

I guess a couple of questions:

1. Why have different signatures?
2. To the extent this is the signature, will buyerReportingId and sellerAndBuyerReportingId be in the sellerReportingMetadata or buyerReportingMetadata.

The client-side API does not change regardless of where the auction logic is executed.

• On Chrome, Advertisers and DSPs will still add the user to the interest group with joinAdInterestGroup(). Publishers and SSPs will trigger the auction with runAdAuction()

• On Android, Advertisers and DSPS will still add the user to a custom audience with joinCustomAudience(). Publishers and SSPs will trigger the auction with selectAds()

The client will send one umbrella request with all the data required for executing bidding and auctions on the server side. Refer to the architecture diagram for more information.

I believe one of the goals of the the sandbox has been to make it easier for consumers to understand how they are being targeted (comment here) and to be able to delete that (I believe I've seen that in a few places but for now can't really find it spelled out, maybe "long term unlinkability" would imply that if PS is adopting that (are you? :) )).

The initial on device version of PaApi enabled this in a pretty strong way with all local storage and processing of IGs and creatives. We've had to make tradeoffs in the move towards B & A and the iterative nature of some of the requirements (i.e. event level reporting till 2026), but in particular I'd like to understand how we'll enforce/try-to-enforce the Interest Group View/Delete-ability with the suggested (and wise) payload optimization of user bidding signals. It seems an important top level privacy goal that gets a bit trickier in a server side world, and while the tradeoff may be worth it (I think it is) we'd want to account for that if we can.

Will there be an expectation that the KV server will provide a GET and DELETE service that the browser can use to pull the bidding signals and delete them? Would that be a technical solve, in that the the browser would do some mini-service-discovery, "enforced" via the attestation, or some combination? Happy to kick this around.

Background
SSP clients will often send a single request to the SSP server with multiple slots for ads available. In our case, this allows us to save significant time and resources on various upfront phases of the auction (traffic filtering, consent, deal eligibility) and has proven empirically important with several important clients. The way this works in our system is that the tech on page collects all of the tags, sends in a single request, generates a request_id that covers the entire request, the SSP server side does the common processing, and then auctions with their own auction_ids are spawned and run in parallel. OpenRTB has support for multi tag as well, although makes no comment on how it should work.

Initial thoughts for B & A flow were that we'd continue to generate the request_id, run the traffic filtering, consent, deal eligibility, etc, in our SSP server, and then coordinate multiple requests to the seller front end.

Concern
After some internal discussion today we're curious how this will work in the Fledge B & A flow. We see that there is a UUID generated client side and the idea is to prevent replay attacks, and are now wondering if that would stop us from invoking auctions with the same interest groups for multiple slots.

Thoughts
If that is currently the case we'd strongly ask that multi-tag support within a single request be made possible via these APIs. Since the thing we want from a privacy perspective is to prevent replay attacks, I think this could be accomplished by having the SFE's return errors on the UUID in a more nuanced way. The client could generate the UUID and the number of tags on the page, generate a UUID for each auction, or some such, and allow them to be run in parallel within some fairly short amount of time.

We were discussing internally and realized we should get more clarification on the biddingScriptUrl deployment. I had assumed a few things:

• The IG on browser will still need to declare it's biddingScriptUrl for compat btw on-device/TEE, and for k-anon purposes.
• If that changes, request makes it to bidding service w/o it ever having seen that biddingScriptUrl before...what happens? Does it pull it down live?

Will the Bidding and Auction Services support parallelization with the "contextual" ad request, as discussed in WICG/turtledove#385?

This repository, privacysandbox/protected-auction-services-docs, is for documentation only.

For discussions, please use the WICG/protected-auction-services-discussion repository.

Couple of questions came up after some internal discussion about TEE usage for the 1% period starting Jan 1 2024:

BA GA Timing
BA timing is currently Alpha starting already, beta in October, Scale Testing Feb 24. Chrome browsers will start the 1% deprecation on Jan 1 2024. Having been a math major, I can proudly state with a high level of certainty that Jan 1 2024 < Feb 2024.

What is the thinking/guidance here? I see many features should be ready during beta, but given the reasons for moving to BA (which we are wholly behind) the BA availability coming after the deprecation is something I'd like to understand better.

Opted In Flag
From the guidance to sellers I see a couple of indications that a flag will be sent from the client to Seller Ad Service, indicating whether the browser is part of the experiment (in particular see Chrome browser will support a flag. Users' browsers that enable the flag can be targeted. and Set up experiments for ad auctions and target user opt-in traffic.). I'm hoping to get a touch more detail on that as I see that conflicting with some of the signaling-of-opt-in/out discussion here.

Will this flag:

• Indicate: 3PC deprecation? Fledge enablement? Or both?
• Be available for the duration of the ramp up period?
• Be available after the ramp up period to indicate opt-outs (Fledge disablement?).

Hello 👋
An initial big thanks for keeping this document up-to-date and alive 🙌

I've kept an eye on the Design Proposal, Developer Guides for FLEDGE, and this page over the past few months.

As bidding_auction_services_api.md has received more updates lately, I find it hard to know which proposal is the "latest" and most accurate/realistic. It would be great to know more about this since the proposals are quite different now and it will make it harder to prepare for the Beta which should happen this year.

A few examples of the differences

• Omission of BiddingLogicURL and it's purpose
• seller+buyer gRPC calls vs. user's device HTTPS calls
• On-device javascript execution vs. self-hosted TEE javascript execution

Cloud Debugger was deprecated in May 2023, but the bidding_auction_services_gcp_guide.md document still references it in the API list despite it no longer being available.

$ gcloud services list --project ps-dev-pa-baservers-978b | grep de                                                                                                          
confidentialcomputing.googleapis.com  Confidential Computing API

Hi,

We will write data to shared storage in the generateBid function (shared storage supports this use case).
It seems difficult to support writing to shared storage in a B&A service, has this use case been considered?

Private Aggregation API is accessible from Protected Audience API on-device model bidding, scoring and reporting scripts.

What of support in Bidding and Auction?

Hi @chatterjee-priyanka

Do you planning to support field experimentGroupId in B&A code and in request to KeyValue service from BuyerFrontEnd?

Because you docs saying that it will be supported here.
However, I don't see that it's supported in code here or here.
At the same time, it's already supported in on-device version, in chromium here.

Could you please confirm that this field will be supported in future? The running of experiments it's important for us.

Are any knobs for shaping and configuring traffic between an SSP and DSP being discussed? In particular I'd think allowing some filters for traffic flowing from the SFE to BFEs would be good, as we currently support different types of filters when sending requests to DSPs to help them manage their traffic and infrastructure. We also allow a bidder to change the location of their DSP collection per DC without requiring a restart on our side.

QPS or other throttling controls are valuable. Our simplest ones are QPS per data center but we do some interesting stuff with dynamically optimizing the bidstream based on auction results or server failure/timeouts (Hystrix'y type stuff). From what I can see so far in the SFE Runtime Flags I'm not seeing anything that seems related to traffic. I do see configurations related to auto-scaling, and that is good, but not all ad techs will want to auto-scale as high as traffic allows, and even with good and infinite auto-scaling in place static and dynamic QPS throttles are still valuable in maintaining a working system.

Additionally on BFE cluster config, am I right that, as of now, if a DSP wanted to change the location of their cluster, they'd have to ask the SSP to restart all of their SFEs with a new config with BFE hosts? And they'd have to do that across any sellers they expect traffic from?

Fwends, I have a diagram coloring request, and yes I'm being super cereal.

One of the critical distinctions when thinking about PPA through B&A is understanding the environment that something is happening in, for instance client, vs your own servers, vs a TEE. We also of course have multiple entities to deal with.

In the main diagram we see background color choice by env type and not by entity, text always black:

• Red = client
• Yellow = untrusted (your servers)
• Green = TEE

In this one from this section in the main explainer I see background coloring by entity and not env type, text always black:

• Red = Client
• Green = Seller, TEE or Untrusted
• Blue = Buyer1
• Grey = Buyer2

In this one from this section of the multi seller, we see background coloring by entity and not env type, text always black:

• Red = Client
• Blue = Seller 1, trusted/untrusted
• Green = Seller 2, trusted/untrusted

My fwends! It would help me, and I wonder if others, if we could Create Coloring Consistency across Multiple Dimensions. I think it will help people to understand the envs and entities if we do something like:

• Use background color for environment, as done in the main diagram (yellow=untrusted, green=tee, red=client), do this consistently across diagrams.
• Use text color for entities, this can be diagram specific.

Hey fwends, I'm hoping for clarification on reportWin/reportResult in BA. Is this correct:

ReportWin() will be executed in Auction service, reporting url for the buyer and registered ad beacons (for Fenced Frame reporting) would be generated in Auction service and returned to the client in encrypted [AuctionResult](https://github.com/privacysandbox/fledge-docs/blob/main/bidding_auction_services_api.md#auctionresult). The client will ping the buyer's reporting endpoint using the reporting url.

Note: A detailed design covering reporting will be published separately.

How will this work in the case that a BA auction is part of a multi-component auction that is occurring on the client, something prebid like, where the client would have a contextual bid it needs to evaluate it might not get prior to the private auction?