Review for Protected Audiences Bidding and Auction Services API

[brusshamilton]

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. 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 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
• 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
• Primary contacts (and their relationship to the specification):
  • Michael Kleber (@michaelkleber), Google
  • Paul Jensen (@JensenPaul), Google
  • B. Russ Hamilton (@brusshamilton), Google
• Organization/project driving the design: Google
• Multi-stakeholder support:
  • Chromium comments: Yes
  • Mozilla comments: Protected Audience API mozilla/standards-positions#770 (comment)
  • WebKit comments: Protected Audience (formerly FLEDGE) WebKit/standards-positions#158 (comment)
• External status/issue trackers for this feature: Chrome Status

Further details:

• [✓] I have reviewed the TAG's Web Platform 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 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 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 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, 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.

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, 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

[jyasskin]

FWIW, https://github.com/WICG/turtledove/blob/main/FLEDGE_browser_bidding_and_auction_API.md doesn't really work as an explainer: it doesn't mention user needs, doesn't show what's possible in the status quo vs the proposed design, and doesn't include alternatives that you've considered. Further, since the TAG has already reviewed Protected Audience and identified several issues, does this feature fix any of the problems identified in that review? If it doesn't, the TAG probably won't spend the time to review a change that just tinkers around the edges (and so it wouldn't be worth your time to improve the explainer).

I got the impression from an API owner that the purpose of this review is to ask us to look at the general idea of offloading computation from the client to "trusted" servers. @maxpassion had a session about that at TPAC and might be interested. But this explainer doesn't really introduce that concept, and I think we'd need something more focused, with several use cases listed, to discuss it productively. Is https://github.com/googleads/conf-data-processing-architecture-reference/blob/main/docs/TrustedExecutionEnvironmentsArchitecturalReference.md the same concept you're looking at here? Should we review that instead?

[jyasskin]

We're looking at this in the context of the overall negative review of Protected Audience from February. The TAG generally thinks that you should only extend problematic and non-consensus features if the extension acts to fix the problems. Our understanding is that this sub-feature does not contribute to addressing the problems we identified in that review, though the request doesn't say either way. If we have that wrong, please document how this change does fix some of the identified problems, and we'll be happy to reopen this review.

If you'd like us to analyze the architectural implications of offloading work to a server that's trustworthy in various ways, please open a separate review about applying that idea to a few more-generally-agreed-on use cases.

[jyasskin]

https://www.w3.org/community/cloud-edge-client/ might or might not be relevant on that last point.