Expose full URL to buyer's K/V server for content/contextual/site targeting

[wing-yahoo-2023]

Yahoo DSP is highly interested in the ability to receive the full URL to our K/V server for Protected Audience buying. This is a prerequisite for scaled adoption of Protected Audience by our customers (advertisers) and enables 2 critical use cases:

1. Contextual / brand safety classification: Yahoo DSP relies on pre-classifying web pages into content categories via offline scanning, and we use the resulting cached per-URL classification data in real time bidding. Our customers expect to configure their campaigns to include/exclude buying and/or modify bids based on content category.
2. Per-campaign site/URL lists: Yahoo DSP customers also expect to be able to restrict campaign delivery to an arbitrary subset of web sites according to domain or URL pattern.

Along with offline loading of per-URL classification data and campaign configuration data into the K/V server, we intend to create a user-defined function (in our K/V server) that would perform efficient filtering of eligible campaigns through trusted bidding signals. We would prefer to implement this as soon as possible within the existing client-side auction environment, as opposed to waiting for future availability of Bidding & Auction Services.

Per existing issue #892 we understand Chrome has considered making the URL available to a K/V server running in TEE mode over an encrypted request protocol. Yahoo DSP would prefer an opt-in feature that can be configured by the buyer only (corresponding to the first suggestion from @michaelkleber in issue #892- "Making it possible for an IG to pick a K/V server which the browser can be sure is running in a TEE"). Assuming that is made available in Chrome, Yahoo DSP would begin testing the capability by creating interest groups with the opt-in flag set and pointing to an instance of our K/V server configured appropriately (running in TEE mode with required encryption keys / attestation etc).

[MattMenke2]

Worth noting that this will potentially significantly reduce cache hit rates, in cases where key/value responses allow caching (particularly for DSPs, where requests are more likely to have the same keys again and again). So we'd probably want to make getting the full URL opt-in, in addition to gating it on using a TEE server.

[peiwenhu]

We (Chrome and TEE KV server team) are discussing internally about the potential approaches and we'll provide some update next week.

[itaysharfi]

We appreciate your interest in using the fully attested production version of the KV server in TEE. Here's what you need to know:

1. Secure Communication: To protect user privacy, the browser will only share the full URL with a KV server using secure, encrypted communication. That means yes a fully attested production version of TEE-based KV server is required to process this data, and this will not be available to BYOS KV server. The TEE KV server’s trust model is explained here and the implementation is available here. KV BYOS only receives hostname and not the full url.
2. Chrome's Commitment: We're currently working on implementing support for version 2 of the KV server protocol, in order to send this information.
3. Timeline: We plan to have a prototype in Q3 2024.