Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

Intent to Ship: Protected Audience: Trusted Key-Value Server Support

276 views
Skip to first unread message

Paul Jensen

unread,
Jan 8, 2025, 11:59:00 AMJan 8
to blink-dev

Contact emails

paulj...@chromium.org


Explainer

https://github.com/WICG/turtledove/pull/1342

https://github.com/WICG/turtledove/pull/1343


Specification

The web platform portion of the specification: https://github.com/WICG/turtledove/pull/1340

The interface to the Trusted Key-Value Server endpoint: https://privacysandbox.github.io/draft-ietf-protected-audience-key-value-service/draft-ietf-protected-audience-key-value-services.html


Summary

During Protected Audience (PA) API ad selection auctions, buyers and sellers are able to fetch real-time signals from servers.  As a temporary mechanism, the buyer and seller can fetch these signals from any server, including one they operate themselves (a "Bring Your Own Server" model); this change does not remove this support. To improve user privacy and enable new functionality, in the future versions of PA, the request will only be sent to a trusted key-value-type server.  The server is verified by external parties to ensure it’s running an approved binary built from the open source key-value server code and is running in a trusted execution environment (TEE), and only then is allowed access to decryption keys.  This proposal adds support to Chrome to communicate with these trusted key-value servers using an encrypted protocol ensuring that only the appropriately trusted servers can decrypt and respond, thus ensuring the protocol and server maintain desired privacy characteristics.


Blink component

Blink>InterestGroups


TAG review

For Protected Audience: https://github.com/w3ctag/design-reviews/issues/723


TAG review status

Completed for PA, resolved unsatisfied.


Risks


Interoperability and Compatibility

Optional new functionality that does not break existing use.


Gecko & WebKit: For PA in general - Negative from Mozilla. No signal from Webkit.


Edge: Edge is running an Origin Trial of the Ad Selection API which shares a Web API and services protocol with PA.


Web developers: At least four companies have expressed interest in another feature (also here) that is blocked on Trusted Key-Value Server Support in the browser.


Debuggability

HTTPS requests to Trusted Key-Value Servers are visible in the Chrome DevTools Network pane.  Response values are visible by setting breakpoints in PA bidding scripts.


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

It will be supported on all platforms that support PA, so all but WebView.


Is this feature fully tested by web-platform-tests?

We have started WPTs and plan to finish them soon.


Flag name on chrome://flags

None


Finch feature name

ProtectedAudienceTrustedKVSupport


Requires code in //chrome?

False


Estimated milestones

Shipping on desktop and Android in M132.


Anticipated spec changes

None


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5072384013631488?gate=5125481377300480


This intent message was generated by Chrome Platform Status.

Yoav Weiss (@Shopify)

unread,
Jan 15, 2025, 10:02:49 AMJan 15
to blink-dev, Paul Jensen
On Wednesday, January 8, 2025 at 5:59:00 PM UTC+1 Paul Jensen wrote:

Can you please point at relevant sections in the explainer, rather than PR diffs?
 

Specification

The web platform portion of the specification: https://github.com/WICG/turtledove/pull/1340


Here as well, pointing to relevant sections of the spec would be helpful.

Paul Jensen

unread,
Jan 15, 2025, 1:29:43 PMJan 15
to Yoav Weiss (@Shopify), blink-dev
The main relevant section of the Protected Audience explainer is 3.1.2 Trusted Signals Server in TEE
The JavaScript API changes are minimal, just the extra trustedBiddingSignalsCoordinator and trustedScoringSignalsCoordinator fields.  The bulk of the browser changes are explained in the explainer for the new protocol used to communicate with the Trusted Key-Value Server.

Similarly, the main relevant sections of the web spec are the sections that assemble the trusted bidding and trusted scoring sections, while the bulk of the new spec is the new IETF spec for the new protocol used to communicate with the Trusted Key-Value Server.

Chris Harrelson

unread,
Jan 16, 2025, 11:41:06 AMJan 16
to Paul Jensen, Yoav Weiss (@Shopify), blink-dev
On Wed, Jan 15, 2025 at 10:29 AM Paul Jensen <paulj...@chromium.org> wrote:
The main relevant section of the Protected Audience explainer is 3.1.2 Trusted Signals Server in TEE
The JavaScript API changes are minimal, just the extra trustedBiddingSignalsCoordinator and trustedScoringSignalsCoordinator fields.  The bulk of the browser changes are explained in the explainer for the new protocol used to communicate with the Trusted Key-Value Server.

Similarly, the main relevant sections of the web spec are the sections that assemble the trusted bidding and trusted scoring sections, while the bulk of the new spec is the new IETF spec for the new protocol used to communicate with the Trusted Key-Value Server.

Thanks for these links. Regarding IETF, what status does that IETF spec have in terms of standards consensus or review at that body?
 
--
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+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABQTWrk0XPEYYdiRKLgN88cQ67TnzeJW7a5WVNdZCcnRp28u5A%40mail.gmail.com.

Paul Jensen

unread,
Jan 17, 2025, 2:28:09 PMJan 17
to Chris Harrelson, Yoav Weiss (@Shopify), blink-dev
Before starting the IETF spec, we reached out to IETF Area Directors for the ART and WIT groups and they advised us to draft the internet drafts for this protocol and the Bidding and Auction Services protocol (which is similar to this protocol and similarly uses OHTTP, HPKE, CBOR) and then submit them to the DISPATCH working groups.  We planned to submit them after getting I2S review and approval, to allow incorporating feedback received during I2S review into the IETF spec.  I'm not aware of any standards review of our internet drafts yet.

Chris Harrelson

unread,
Jan 17, 2025, 2:47:30 PMJan 17
to Paul Jensen, Yoav Weiss (@Shopify), blink-dev

Vladimir Levin

unread,
Jan 22, 2025, 9:21:12 AMJan 22
to Chris Harrelson, Paul Jensen, Yoav Weiss (@Shopify), blink-dev

Yoav Weiss (@Shopify)

unread,
Jan 22, 2025, 10:00:28 AMJan 22
to Vladimir Levin, Chris Harrelson, Paul Jensen, blink-dev
LGTM3
Reply all
Reply to author
Forward
0 new messages