Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Protected Audience Opt-In TEE K/V Mode #892

Open
michaelkleber opened this issue Nov 6, 2023 · 4 comments
Open

Protected Audience Opt-In TEE K/V Mode #892

michaelkleber opened this issue Nov 6, 2023 · 4 comments
Labels
Looking for feedback Design issues looking for partner feedback

Comments

@michaelkleber
Copy link
Collaborator

Chrome is interested in building an opt-in mode for the Protected Audience API that would require Key/Value servers to run inside of TEEs. We are interested in feedback on whether it would get any use.

Recall that Protected Audience API will eventually require K/V servers to run inside TEEs, but that this is not yet required. We are considering:

  1. Making it possible for an IG to pick a K/V server which the browser can be sure is running in a TEE
  2. Making it possible for a particular PA auction to declare "I am only willing to talk to TEE K/V servers" — which would mean the auction would exclude IGs that don't do 1
  3. Making it possible for web pages to opt in to this behavior even before Chrome is ready to require it. That is,
    1. Letting a page allow only IG Join operations that do 1
    2. Letting a page allow only PA auctions that do 2

Once the K/V server is running inside a TEE, the browser can be more relaxed about information sent to the server. For example, K/V requests today only include the domain name of the site where the auction is happening. A K/V inside a TEE could safely receive the full page URL. (Although if your goal is more signals inside a TEE, consider the Bidding & Auction Services path — the Bidding Service will always have more signals available, since generateBid runs there.)

Question: Would anyone use this?

Of course this will take work from the Chrome team, and we don't want to spend our resources building something that nobody will use. We are interested in hearing expressions of interest from any part of the ecosystem — buy-side ad tech who might try 1, sell-side ad tech who might try 2, advertisers or other audience builders who might try 3(i), and publishers who might try 3(ii). (Note that there's no point in sites trying 3 unless some ad techs are trying 1 and 2.)

@michaelkleber michaelkleber added the Looking for feedback Design issues looking for partner feedback label Nov 6, 2023
@k-o-ta
Copy link
Contributor

k-o-ta commented Nov 29, 2023

I guess that when a buyer is using a K/V running on TEE, the buyer knows that the browser will use the K/V on TEE without activating the 1st flag.
Is the 1st flag used to declare and guarantee that a buyer is running K/V server on TEE for sellers?

@kodaikureishi
Copy link
Contributor

The proposal is interesting and promotes a developer to implement TEE server!

I have a question about your idea.
When web page only allow IG join operations, but all buyer-side adtech is not ready to run in TEE, what happen?

@peiwenhu
Copy link
Contributor

@k-o-ta When a buyer is using a TEE K/V, its URL itself is not more special. So technically the browser would not be able to know if a K/V runs inside TEE unless the buyer indicates it via some other IG configuration (The browser can also know it by making an extra call to the server but that is unnecessarily costly) so the 1st flag is for the browser to know (The browser can verify afterwards but it first needs to know).

@k-o-ta
Copy link
Contributor

k-o-ta commented Dec 3, 2023

@peiwenhu Thank you for your replying. I understand the use-case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Looking for feedback Design issues looking for partner feedback
Projects
None yet
Development

No branches or pull requests

4 participants