-
Notifications
You must be signed in to change notification settings - Fork 256
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
Comments
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. |
The proposal is interesting and promotes a developer to implement TEE server! I have a question about your idea. |
@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). |
@peiwenhu Thank you for your replying. I understand the use-case. |
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:
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.)
The text was updated successfully, but these errors were encountered: