Intent to Ship: Protected Audience Bidding & Auction Services

[Russ Hamilton]

Contact emails

paulj...@chromium.org, beham...@google.com

Explainer

Chrome:  https://github.com/WICG/turtledove/blob/main/FLEDGE_browser_bidding_and_auction_API.md

Services: https://github.com/privacysandbox/fledge-docs/blob/main/bidding_auction_services_api.md

Specification

The web platform portion of the specification (navigator.getInterestGroupAdAuctionData() and the server response changes to navigator.runAdAuction()) is part of the Protected Audience spec.

The interface to the Bidding & Auction Services endpoint is described in https://privacysandbox.github.io/draft-ietf-bidding-and-auction-services/draft-ietf-bidding-and-auction-services.html

Summary

The Protected Audience API (formerly known as FLEDGE) is a Privacy Sandbox proposal to serve remarketing and custom audience use cases, designed so third parties cannot track user browsing behavior across sites. This proposal, the Protected Audience Bidding & Auction Services API, outlines a way to allow Protected Audience computation to take place on cloud servers in a Trusted Execution Environment (TEE), rather than running locally on a user's device. Moving computations to cloud servers can help optimize the Protected Audience auction, to free up computational cycles and network bandwidth for a device.

Blink component

Blink>InterestGroups

TAG review

For Protected Audience: https://github.com/w3ctag/design-reviews/issues/723

TAG review status

Completed for Protected Audience, resolved unsatisfied.

Risks

Interoperability and Compatibility

None. This is an optional new feature of the Protected Audience API. Ad techs can use this new feature by calling navigator.getInterestGroupAdAuctionData() and specifying values for new fields in the auction config. Without invoking the new function or explicit values for those new fields, there's no functional behavioral change as a result of this feature.

Gecko & WebKit: No signal on parent proposal, Protected Audience.  Asked in the Mozilla forum here, and in the Webkit forum here.

Edge: Microsoft has proposed their Ad Selection API as a similar TEE on-server auction API. That API looks like it would have a near identical Web Platform API as the Bidding and Auction Services API. We have biweekly meetings with Microsoft, and are open to collaborating on specifying the API.

Web developers: Extensive interest in this feature from adtechs, evidenced by the myriad of discussions on Protected Audience’s issue tracker, Protected Audience’s weekly WICG calls, and the Protected Auction Services WICG calls.

Debuggability

On-device API surfaces should be debuggable in Chrome DevTools, and we’ve added extensive mechanisms for debugging Bidding and Auction services.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

It will be supported on all platforms that support Protected Audience, so all but WebView.

Is this feature fully tested by web-platform-tests?

Lots of  WPT tests. Remaining test coverage to be completed soon.

Flag name on chrome://flags

Overall control is not possible via chrome://flags, though the consented debugging support is controlled via chrome://flags/#protected-audience-debug-token

Finch feature name

FledgeBiddingAndAuctionServer

Requires code in //chrome?

Only for UI for the consented debugging support.

Anticipated spec changes

No web-visible changes expected.

Estimated milestones

Shipping to all applicable platforms in M130.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4649601971257344

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABQTWrnSdvf7RgK2wxsmC6rWc8eRoqDZOvgwVFuEx1r2nqmAJg%40mail.gmail.com

Intent to Experiment:

https://groups.google.com/a/chromium.org/g/blink-dev/c/2bwMHd3Yz7I

Intent to Extend Experiment:

https://groups.google.com/a/chromium.org/g/blink-dev/c/2bwMHd3Yz7I/m/xaJHFJ_uAAAJ

Intent to Extend Experiment 2:

https://groups.google.com/a/chromium.org/g/blink-dev/c/2bwMHd3Yz7I/m/RigQFZilAgAJ

[Mike Taylor]

On 10/7/24 10:30 AM, 'Russ Hamilton' via blink-dev wrote:

Contact emails

paulj...@chromium.org, beham...@google.com

Explainer

Chrome:  https://github.com/WICG/turtledove/blob/main/FLEDGE_browser_bidding_and_auction_API.md

Thanks - this was helpful to read.

Services: https://github.com/privacysandbox/fledge-docs/blob/main/bidding_auction_services_api.md

Specification

The web platform portion of the specification (navigator.getInterestGroupAdAuctionData() and the server response changes to navigator.runAdAuction()) is part of the Protected Audience spec.

The interface to the Bidding & Auction Services endpoint is described in https://privacysandbox.github.io/draft-ietf-bidding-and-auction-services/draft-ietf-bidding-and-auction-services.html

Summary

The Protected Audience API (formerly known as FLEDGE) is a Privacy Sandbox proposal to serve remarketing and custom audience use cases, designed so third parties cannot track user browsing behavior across sites. This proposal, the Protected Audience Bidding & Auction Services API, outlines a way to allow Protected Audience computation to take place on cloud servers in a Trusted Execution Environment (TEE), rather than running locally on a user's device. Moving computations to cloud servers can help optimize the Protected Audience auction, to free up computational cycles and network bandwidth for a device.

Blink component

Blink>InterestGroups

TAG review

For Protected Audience: https://github.com/w3ctag/design-reviews/issues/723

TAG review status

Completed for Protected Audience, resolved unsatisfied.

Risks

Interoperability and Compatibility

None. This is an optional new feature of the Protected Audience API. Ad techs can use this new feature by calling navigator.getInterestGroupAdAuctionData() and specifying values for new fields in the auction config. Without invoking the new function or explicit values for those new fields, there's no functional behavioral change as a result of this feature.

Gecko & WebKit: No signal on parent proposal, Protected Audience.  Asked in the Mozilla forum here, and in the Webkit forum here.

Edge: Microsoft has proposed their Ad Selection API as a similar TEE on-server auction API. That API looks like it would have a near identical Web Platform API as the Bidding and Auction Services API. We have biweekly meetings with Microsoft, and are open to collaborating on specifying the API.

Can you elaborate more on "near identical"? Would it be possible to have an interoperable server-bidding API between the two proposals in the near term?

Web developers: Extensive interest in this feature from adtechs, evidenced by the myriad of discussions on Protected Audience’s issue tracker, Protected Audience’s weekly WICG calls, and the Protected Auction Services WICG calls.

Debuggability

On-device API surfaces should be debuggable in Chrome DevTools, and we’ve added extensive mechanisms for debugging Bidding and Auction services.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

It will be supported on all platforms that support Protected Audience, so all but WebView.

Is this feature fully tested by web-platform-tests?

Lots of  WPT tests. Remaining test coverage to be completed soon.

Can you comment on what tests (or types of tests) are missing, and when you expect them to be done?

Flag name on chrome://flags

Overall control is not possible via chrome://flags, though the consented debugging support is controlled via chrome://flags/#protected-audience-debug-token

Finch feature name

FledgeBiddingAndAuctionServer

Requires code in //chrome?

Only for UI for the consented debugging support.

Just the chrome://flags UI, right? Or is there some other debugging UI that gets enabled when flipping that on?

Anticipated spec changes

No web-visible changes expected.

Just to confirm, you're adding a new web-visible API (and have specced that) but are not changing any other PA APIs, correct?

Estimated milestones

Shipping to all applicable platforms in M130.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4649601971257344

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABQTWrnSdvf7RgK2wxsmC6rWc8eRoqDZOvgwVFuEx1r2nqmAJg%40mail.gmail.com

Intent to Experiment:

https://groups.google.com/a/chromium.org/g/blink-dev/c/2bwMHd3Yz7I

Intent to Extend Experiment:

https://groups.google.com/a/chromium.org/g/blink-dev/c/2bwMHd3Yz7I/m/xaJHFJ_uAAAJ

Intent to Extend Experiment 2:

https://groups.google.com/a/chromium.org/g/blink-dev/c/2bwMHd3Yz7I/m/RigQFZilAgAJ

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAG-DU3H_eSNfb7gzNn-OTbdvqsatiZMP53m1pN_3TpyNrzoeA%40mail.gmail.com.

[Yoav Weiss (@Shopify)]

On Wednesday, October 16, 2024 at 4:00:00 PM UTC+2 Mike Taylor wrote:

On 10/7/24 10:30 AM, 'Russ Hamilton' via blink-dev wrote:

Contact emails

paulj...@chromium.org, beham...@google.com

Explainer

Chrome:  https://github.com/WICG/turtledove/blob/main/FLEDGE_browser_bidding_and_auction_API.md

Thanks - this was helpful to read.

Services: https://github.com/privacysandbox/fledge-docs/blob/main/bidding_auction_services_api.md

Given that this service spec defines the protocols browsers and services would need to implement, could you move this to a more public venue? (where non-Google employees can comment, and files issues and PRs) 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Russ Hamilton]

> Can you elaborate more on "near identical"? Would it be possible to have an interoperable server-bidding API between the two proposals in the near term?

I believe the browser API is identical, though I'm not as sure about how they are handling coordinators and key distribution. There is a difference in the privacy model that affects how the bidding and scoring worklets work, so those (server-side) scripts will not be identical. 

> Can you comment on what tests (or types of tests) are missing, and when you expect them to be done?

I looked through the tests and it looks like all the remaining tests have landed since the I2S was sent out. There are a couple of TODOs in the tests, but they are for features that are intended to launch later and so are not part of this I2S.

> Just the chrome://flags UI, right? Or is there some other debugging UI that gets enabled when flipping that on?

It's mostly the chrome://flags UI. There is also an infobar that shows up when consented debugging is enabled (so the user is aware that they have opted in to allowing server-side debugging).

> Just to confirm, you're adding a new web-visible API (and have specced that) but are not changing any other PA APIs, correct?

Yes, we are adding a new web-visible API and extending the PA runAdAuction API to support the server-side auction use case. There should be no compatibility changes with the existing APIs.

Best,

--Benjamin "Russ" Hamilton

[Paul Jensen]

Yoav, our IETF service spec repository is already public and we verified anyone can file issues there.  We also verified with more experienced standardization folks that its IPR settings look right.

[Paul Jensen]

Erik,

Edge recently started an Origin Trial for the Ad Selection API, and I had three questions about its compatibility with Protected Audience Bidding & Auction Services:

1. The Ad Selection API details says it “aims to maximize syntactic compatibility with the Protected Audience API”.  Can you confirm that the Ad Selection API uses nearly the same web API as specified in the Protected Audience API specification?

2. Is the Ad Selection API also using similar request and response encoding and encryption as specified in the Bidding and Auction Services specification?

3. We recently posted the location and format of the coordinator keys that Chrome fetches.  Does the Ad Selection API use a similar mechanism?

[Paul Jensen]

On a related note, we requested a TAG review of Bidding and Auction Services here, and updated our standards-positions-asks to mention Bidding and Auction Services here and here.

[Mike Taylor]

Thanks -

LGTM1

[Yoav Weiss (@Shopify)]

LGTM2

[Erik Anderson]

Hi everyone,

Re: Ad Selection API and how it relates to Protect Audience API. As we’ve discussed in various forums, while there are important differences in our proposal vs. Bidding & Auction Services, we have a general goal to minimize the amount of work a developer needs to do in order to target both APIs. As a result, yes, the APIs are currently very closely aligned and we will proactively raise concerns via the associated GitHub repos and public calls if/where we think that is no longer possible.

At the same time, there is one very large difference: the cloud TEE provider matrix. Microsoft is continuing to listen to feedback from the ecosystem about cloud execution environments for these TEE-based APIs. Our preview of the Ad Selection API currently supports Azure while Bidding & Auction Services supports AWS and GCP.

My understanding is that the Azure team has been talking with the Bidding & Auction Services team for approximately the past year in the hopes of getting onboarded as a cloud provider. The Azure team believes they have met all of the criteria defined by Google for supporting public clouds and is actively maintaining a fork that includes Azure support. While that conversation is ongoing, we are deeply concerned that there is still no concrete timeline for support. Furthermore, Azure support is now being coupled to other longer-term milestones in the design of B&A. As a result, the Microsoft Ads team has been unable to broadly test this API in large part due to the dependency on Azure support. The Microsoft Azure team is open to feedback about how they can help accelerate things.

Re: the request and response encoding in Ad Selection API. Yes, Ad Selection API leverages the same encryption as Bidding & Auction services.

Re: the location and format of the coordinator keys that Chrome fetches. From a client browser perspective, it looks the same—Microsoft Edge provides a public key endpoint and uses the same key list schema. On the key management service side, Azure’s implementation looks a little different than what I believe you’re doing with AWS and GCP, but I believe that detail is out of scope here.

Thanks,

Erik

Thanks -

LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Paul Jensen]

Hi OWNERS,
Regarding compatibility between Chrome and Edge, as you can see from the above, the browser API and the wire protocol are aligned, and both browsers are working to maintain that.  The difference here is on policy questions about a choice of what cryptographic keys to use, but implementations are compatible across cloud platforms.

[Chris Harrelson]

Thanks Paul. Glad to hear there isn't a compat risk across cloud platforms.

Erik, could you also confirm that there shouldn't be a technical reason the Edge implementation won't be compatible with AWS and GCP over time?

LGTM3 (not blocking on the above question).

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABQTWrnbGCS%3D4gw3gtArJk5K4KyZT6g07Zog_aBqQhuj%3Doiz9g%40mail.gmail.com.

[Erik Anderson]

Hi Chris,

 

Microsoft Edge would like to see broader cloud support with the Ad Selection API. We are looking for feedback and requests from developers and/or cloud operators to determine the timing of support. We are confident that both AWS and GCP can be supported in the future if there is both developer interest and those clouds want to support it. In fact, we would prefer to have this in place before broadly shipping the API in Microsoft Edge to maximize developer feedback opportunity during the trial phase.

 

We also believe, based on the actively maintained fork (but which has not been accepted or approved thus far), that Azure support would be relatively straightforward for Protected Audience Bidding & Auction Services. I do not know what additional feedback Azure-dependent developers might have able to provide for this intent to ship had such support been present already.

 

Thanks!