[w3ctag/design-reviews] Review for Protected Audiences Bidding and Auction Services API (Issue #1009)

Hello TAG,

I’m requesting a TAG review of the Bidding and Auction Services API for Protected Audiences. Protected Audiences was reviewed here as [#723](https://github.com/w3ctag/design-reviews/issues/723). The Bidding and Auction Services API extends the Protected Audiences API by allowing the computation to take place on cloud servers in a Trusted Execution Environment, instead of the isolated worklet environment used in the on-device approach we have launched so far We wanted to bring to your attention the way that this API allows for real-time trusted computation on private data in a cloud server as we feel it provides a significant capability that may be beneficial to other APIs going forward.  Note that this is not the first API to leverage computation on private data in a TEE, [Private Aggregation](https://github.com/w3ctag/design-reviews/issues/846) already does so. This is the first API in the Privacy Sandbox to include TEE computation in real-time however.


Explainer: see [Protected Audience Browser Bidding and Auction Services API](https://github.com/WICG/turtledove/blob/main/FLEDGE_browser_bidding_and_auction_API.md)
Specification:
https://wicg.github.io/turtledove/
https://privacysandbox.github.io/draft-ietf-bidding-and-auction-services/draft-ietf-bidding-and-auction-services.html
WPT Tests:
https://github.com/web-platform-tests/wpt/blob/master/fledge/tentative/get-interest-group-auction-data.https.window.js
https://github.com/web-platform-tests/wpt/blob/master/fledge/tentative/server-response.https.window.js
Security and Privacy self-review: See below
GitHub repo: [WICG/turtledove](https://github.com/WICG/turtledove)
Primary contacts (and their relationship to the specification):
Michael Kleber ([@michaelkleber](https://github.com/michaelkleber)), Google
Paul Jensen ([@JensenPaul](https://github.com/JensenPaul)), Google
B. Russ Hamilton ([@brusshamilton](https://github.com/brusshamilton)), Google
Organization/project driving the design: Google
Multi-stakeholder support:
Chromium comments: Yes
Mozilla comments: https://github.com/mozilla/standards-positions/issues/770#issuecomment-2432124085
WebKit comments: https://github.com/WebKit/standards-positions/issues/158#issuecomment-2432121278
External status/issue trackers for this feature: [Chrome Status](https://chromestatus.com/feature/4649601971257344)
Further details:
[✓] I have reviewed the TAG's [Web Platform Design Principles](https://www.w3.org/TR/design-principles/)
The group where the incubation/design work on this is being done: WICG
The group where standardization of this work is intended to be done ("unknown" if not known): unknown
Existing major pieces of multi-stakeholder review or discussion of this design:
Issue trackers: https://github.com/WICG/turtledove/issues
Major unresolved issues with or opposition to this design:
There are many issues under discussion in the issue tracker but no major opposition.
This work is being funded by: Google
We'd prefer the TAG provide feedback as (please delete all but the desired option):
🐛 open issues in our GitHub repo for each point of feedback
Security/Privacy Questionnaire
This section contains answers to the [W3C TAG Security and Privacy](https://w3ctag.github.io/security-questionnaire/) [Questionnaire](https://w3ctag.github.io/security-questionnaire/).
1. What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?
Protected Audience’s Bidding and Auction Service feature performs the auction using a server running in a Trusted Execution Environment (TEE) running code that does not expose information to Web sites or other parties beyond that of [the Protected Audience API](https://github.com/w3ctag/design-reviews/issues/723) executing purely on-device.  To start the on-server auction, Web sites use the Bidding and Auction Services API to get a request blob that is encrypted and padded to prevent exposing interest group information from other sites to the site requesting the blob.  Only servers running approved binaries in an appropriate TEE are given the decryption keys to decrypt the blob.
2. Do features in your specification expose the minimum amount of information necessary to enable their intended uses?
Yes, see above answer for ways information exposure is minimized.
3. How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?
Protected Audiences should not deal with personal information, PII or information derived from them. Callers of the API may make choices (for example, which interest groups to add a browser to) based on this sort of information, so group membership is not exposed to sites, as in question 1.
4. How do the features in your specification deal with sensitive information?
Same answer as # 3.
5. Do the features in your specification introduce a new state for an origin that persists across browsing sessions?
No, only the existing state kept by [Protected Audiences](https://github.com/w3ctag/design-reviews/issues/723) is kept.
6. Do the features in your specification expose information about the underlying platform to origins?
Protected Audience’s Bidding and Auction Service feature may expose information about which Coordinators are supported by this User Agent.
7. Does this specification allow an origin to send data to the underlying platform?
No
8 Do features in this specification allow an origin access to sensors on a user’s device
No
9. Do features in this specification enable new script execution/loading mechanisms?
Not in the browser; but scripts previously run in the browser can now be executed in TEEs.
10. Do features in this specification allow an origin to access other devices?
No
11. Do features in this specification allow an origin some measure of control over a user agent’s native UI?
No
12. What temporary identifiers do the features in this specification create or expose to the web?
None.
13. How does this specification distinguish between behavior in first-party and third-party contexts?
The Bidding and Auction Services feature of Protected Audience inherits the mechanisms from [Protected Audiences](https://github.com/w3ctag/design-reviews/issues/723), which defines various steps to control access to its APIs in third-party contexts. See the paragraph that starts with “The browser will only allow the” [here](https://github.com/WICG/turtledove/blob/main/FLEDGE.md#11-joining-interest-groups).
14. How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?
The Bidding and Auction Services feature of Protected Audience inherits its behavior from [Protected Audiences](https://github.com/w3ctag/design-reviews/issues/723), which uses an in-memory interest group store that is separate from the one used by the default browsing mode.
15. Does this specification have both "Security Considerations" and "Privacy Considerations" sections?
Yes.
16. Do features in your specification enable origins to downgrade default security protections?
No
17. How does your feature handle non-"fully active" documents?
Actions are gated by “fully active” checks.
18. What should this questionnaire have asked?
N/A


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1009
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1009@github.com>