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
From: Yoav Weiss (@Shopify) <yoavwe...@chromium.org> Sent: Wednesday, October 30, 2024 3:10 AM To: blink-dev <blink-dev@chromium.org> Cc: Mike Taylor <miketa...@chromium.org>; blink-dev <blink-dev@chromium.org>; Manny Isu <manny...@google.com>; beham...@google.com <behamil...@google.com>; Yoav Weiss <yoavwe...@chromium.org>; Erik Anderson <erik.ander...@microsoft.com>; Paul Jensen <pauljen...@chromium.org> Subject: Re: [blink-dev] Intent to Ship: Protected Audience Bidding & Auction Services LGTM2 On Tuesday, October 29, 2024 at 7:27:52 PM UTC+1 Mike Taylor wrote: Thanks - LGTM1 On 10/29/24 10:33 AM, Paul Jensen wrote: On a related note, we requested a TAG review of Bidding and Auction Services here<https://github.com/w3ctag/design-reviews/issues/1009>, and updated our standards-positions-asks to mention Bidding and Auction Services here<https://github.com/WebKit/standards-positions/issues/158#issuecomment-2432121278> and here<https://github.com/mozilla/standards-positions/issues/770#issuecomment-2432124085>. On Wed, Oct 23, 2024 at 12:29 PM Paul Jensen <pauljen...@chromium.org<mailto:pauljen...@chromium.org>> wrote: Erik, Edge recently started an Origin Trial for the Ad Selection API<https://blogs.windows.com/msedgedev/2024/10/08/ad-selection-api-limited-preview/>, and I had three questions about its compatibility with Protected Audience Bidding & Auction Services: 1. The Ad Selection API details<https://github.com/WICG/privacy-preserving-ads/blob/main/API%20Details.md> 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<https://wicg.github.io/turtledove/>? 2. Is the Ad Selection API also using similar request and response encoding and encryption as specified in the Bidding and Auction Services specification<https://privacysandbox.github.io/draft-ietf-bidding-and-auction-services/draft-ietf-bidding-and-auction-services.html>? 3. We recently posted the location and format of the coordinator keys that Chrome fetches<https://github.com/WICG/turtledove/pull/1309/files>. Does the Ad Selection API use a similar mechanism? On Fri, Oct 18, 2024 at 4:09 PM Paul Jensen <pauljen...@chromium.org<mailto:pauljen...@chromium.org>> wrote: Yoav, our IETF service spec repository<https://github.com/privacysandbox/draft-ietf-bidding-and-auction-services> 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. On Wed, Oct 16, 2024 at 10:23 AM Yoav Weiss (@Shopify) <yoavwe...@chromium.org<mailto:yoavwe...@chromium.org>> wrote: 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 pauljen...@chromium.org<mailto:pauljen...@chromium.org>, behamil...@google.com<mailto:behamil...@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) 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<https://wicg.github.io/turtledove/>. 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<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EInterestGroups> 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<https://github.com/mozilla/standards-positions/issues/770>, and in the Webkit forum here<https://github.com/WebKit/standards-positions/issues/158>. Edge: Microsoft has proposed their Ad Selection API<https://github.com/WICG/privacy-preserving-ads/tree/main> 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<https://github.com/WICG/turtledove/issues>, Protected Audience’s weekly WICG calls<https://github.com/WICG/turtledove/issues/88>, and the Protected Auction Services WICG calls<https://github.com/WICG/protected-auction-services-discussion/issues/27>. Debuggability On-device API surfaces should be debuggable in Chrome DevTools, and we’ve added extensive mechanisms for debugging<https://github.com/privacysandbox/fledge-docs/blob/main/debugging_protected_audience_api_services.md> Bidding and Auction services<https://github.com/privacysandbox/protected-auction-services-docs/blob/main/bidding_auction_services_api.md#related-documents>. 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<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>? Lots of<https://github.com/web-platform-tests/wpt/blob/master/fledge/tentative/get-interest-group-auction-data.https.window.js> WPT tests<https://github.com/web-platform-tests/wpt/blob/master/fledge/tentative/server-response.https.window.js>. 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<https://github.com/privacysandbox/fledge-docs/blob/main/debugging_protected_audience_api_services.md#adtech-consented-debugging> 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<https://github.com/privacysandbox/fledge-docs/blob/main/debugging_protected_audience_api_services.md#adtech-consented-debugging>. 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<https://groups.google.com/a/chromium.org/g/blink-dev/c/2bwMHd3Yz7I/m/BwMKwPP6GQAJ> 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+unsubscr...@chromium.org<mailto:blink-dev+unsubscr...@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<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAG-DU3H_eSNfb7gzNn-OTbdvqsatiZMP53m1pN_3TpyNrzoeA%40mail.gmail.com?utm_medium=email&utm_source=footer>. -- 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+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/DM6PR00MB08301CD1C098A6213FD5B8DDF4552%40DM6PR00MB0830.namprd00.prod.outlook.com.
