Intent to Ship: Protected Audience directFromSellerSignals via HTTP response headers

630 views
Skip to first unread message

Paul Jensen

unread,
Sep 5, 2023, 3:55:38 PM9/5/23
to blink-dev

Contact emails

paulj...@chromium.org


Explainer

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


Specification

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

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


Summary

Protected Audience already supports a mechanism to ensure the authenticity and integrity of information passed into the auction from the seller called directFromSellerSignals. Currently this is implemented by the seller providing subresources in a WebBundle to the browser, which after a year of testing has proved to not be as efficient as originally planned. It either requires an entirely new additional fetch of a WebBundle, or for the seller to rewrite and rework an existing fetch to respond instead with only a WebBundle. This feature is a rewrite of directFromSellerSignals to use an HTTP response header, transferred via HTTPS same-origin with the seller, instead of a WebBundle to optimize performance.


Blink component

Blink>InterestGroups


TAG review

The parent proposal, Protected Audience, is still pending: https://github.com/w3ctag/design-reviews/issues/723


TAG review status

Pending


Risks


Interoperability and Compatibility

None as this is an optional new way of providing directFromSellerSignals.  It cannot be used jointly with the old mechanism, but there shouldn’t be a need to use the old mechanism.


Gecko & WebKit: No signal on parent proposal, Protected Audience.  Asked in the Mozilla forum here, and in the Webkit forum  here.


Web developers: Adtech asked for this via this Protected Audience Github issue.



Debuggability

This feature affects values provided to Protected Audience scripts (generateBid(), reportResult(), reportWin()) which are debuggable via Chrome DevTools.  This feature also includes console log warnings on parse failures.


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

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


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

We plan to add WPTs to cover this API in the next month.


Flag name on chrome://flags

None


Finch feature name

FledgeDirectFromSellerSignalsHeaderAdSlot


Requires code in //chrome?

False


Estimated milestones

Shipping on desktop and Android in M117.


Anticipated spec changes

None related to this feature.


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5165311598264320


This intent message was generated by Chrome Platform Status.


Yoav Weiss

unread,
Sep 6, 2023, 12:15:45 PM9/6/23
to Paul Jensen, blink-dev
On Tue, Sep 5, 2023 at 9:55 PM Paul Jensen <paulj...@chromium.org> wrote:

Can you clarify what this does, as the explainer is not very explain-y?

IIUC, the current flow to get directFromSellerSignals is to download a response A which contains a link to a WBN, then download the WBN and that contains the signal info.
Your proposal is to change that so that the directFromSellerSignals information would be embedded in a response header on response A?

If so, any more details on that header? What would be the header name? What payload sizes should we expect for the header's value? In what conditions will it actually be processed?
--
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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABQTWrkbaAuRoxPUtrQnxyS-W%3DfZjba1JN%2BHCHyLmKCKveHXOg%40mail.gmail.com.

Caleb Raitto

unread,
Sep 7, 2023, 12:00:56 PM9/7/23
to blink-dev, Yoav Weiss, blink-dev, Paul Jensen
Hi Yoav, some responses inline:

On Wednesday, September 6, 2023 at 12:15:45 PM UTC-4 Yoav Weiss wrote:
On Tue, Sep 5, 2023 at 9:55 PM Paul Jensen <paulj...@chromium.org> wrote:

Can you clarify what this does, as the explainer is not very explain-y?

IIUC, the current flow to get directFromSellerSignals is to download a response A which contains a link to a WBN, then download the WBN and that contains the signal info.
Your proposal is to change that so that the directFromSellerSignals information would be embedded in a response header on response A?

The original directFromSellerSignals worked by downloading a response A, from the seller’s origin, that is a WBN containing several subresources that represent signals from the seller to various auction participants -- no linking was involved.


You’re correct about this header-based version of directFromSellerSignals -- when Chrome downloads a response, from the seller’s origin, with fetch(..., {adAuctionHeaders: true}), the Ad-Auction-Signals header gets parsed as JSON to provide the signals.
 

If so, any more details on that header? What would be the header name? What payload sizes should we expect for the header's value? In what conditions will it actually be processed?

The name of the header is Ad-Auction-Signals, as mentioned here in the explainer: [0]. Currently, the payload size is limited to 1kb [1], but we’re considering increasing that to 10kb based on feedback. When Chrome conducts a Protected Audience auction, it processes any received Ad-Auction-Signals headers whose adSlot matches that of the auction.  The header contains JSON that dictates which signals are sent to which auction participants.


[0] https://github.com/WICG/turtledove/pull/695/files#diff-d65ba9778fe3af46de3edfce2266b5b035192f8869280ec07179963b81f4e624R465


[1] https://source.chromium.org/chromium/chromium/src/+/main:content/browser/interest_group/ad_auction_url_loader_interceptor.cc;l=195;drc=dcd52bb9a48216858a950b919383c44a290273f7


Thanks,

-Caleb 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Mike Taylor

unread,
Sep 11, 2023, 6:55:40 AM9/11/23
to Caleb Raitto, blink-dev, Yoav Weiss, Paul Jensen

On 9/7/23 6:00 PM, Caleb Raitto wrote:

Hi Yoav, some responses inline:

On Wednesday, September 6, 2023 at 12:15:45 PM UTC-4 Yoav Weiss wrote:
On Tue, Sep 5, 2023 at 9:55 PM Paul Jensen <paulj...@chromium.org> wrote:

Can you clarify what this does, as the explainer is not very explain-y?

IIUC, the current flow to get directFromSellerSignals is to download a response A which contains a link to a WBN, then download the WBN and that contains the signal info.
Your proposal is to change that so that the directFromSellerSignals information would be embedded in a response header on response A?

The original directFromSellerSignals worked by downloading a response A, from the seller’s origin, that is a WBN containing several subresources that represent signals from the seller to various auction participants -- no linking was involved.


You’re correct about this header-based version of directFromSellerSignals -- when Chrome downloads a response, from the seller’s origin, with fetch(..., {adAuctionHeaders: true}), the Ad-Auction-Signals header gets parsed as JSON to provide the signals.
 

If so, any more details on that header? What would be the header name? What payload sizes should we expect for the header's value? In what conditions will it actually be processed?

The name of the header is Ad-Auction-Signals, as mentioned here in the explainer: [0]. Currently, the payload size is limited to 1kb [1], but we’re considering increasing that to 10kb based on feedback. When Chrome conducts a Protected Audience auction, it processes any received Ad-Auction-Signals headers whose adSlot matches that of the auction.  The header contains JSON that dictates which signals are sent to which auction participants.


[0] https://github.com/WICG/turtledove/pull/695/files#diff-d65ba9778fe3af46de3edfce2266b5b035192f8869280ec07179963b81f4e624R465


[1] https://source.chromium.org/chromium/chromium/src/+/main:content/browser/interest_group/ad_auction_url_loader_interceptor.cc;l=195;drc=dcd52bb9a48216858a950b919383c44a290273f7

Thanks for the explanation - what's preventing https://github.com/WICG/turtledove/pull/695 from landing? It seems rather old (and references stuff that no longer exists, like `X-FLEDGE-Auction-Only`. (It also doesn't seem to define any error-handling for parsing the JSON that a server returns, which would be good to do.)
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5c238b79-7120-4089-a8d7-dc1e67f956fcn%40chromium.org.

Mike Taylor

unread,
Sep 11, 2023, 11:18:26 AM9/11/23
to Caleb Raitto, blink-dev, Yoav Weiss, Paul Jensen


On 9/11/23 12:55 PM, Mike Taylor wrote:

On 9/7/23 6:00 PM, Caleb Raitto wrote:

Hi Yoav, some responses inline:

On Wednesday, September 6, 2023 at 12:15:45 PM UTC-4 Yoav Weiss wrote:
On Tue, Sep 5, 2023 at 9:55 PM Paul Jensen <paulj...@chromium.org> wrote:

Can you clarify what this does, as the explainer is not very explain-y?

IIUC, the current flow to get directFromSellerSignals is to download a response A which contains a link to a WBN, then download the WBN and that contains the signal info.
Your proposal is to change that so that the directFromSellerSignals information would be embedded in a response header on response A?

The original directFromSellerSignals worked by downloading a response A, from the seller’s origin, that is a WBN containing several subresources that represent signals from the seller to various auction participants -- no linking was involved.


You’re correct about this header-based version of directFromSellerSignals -- when Chrome downloads a response, from the seller’s origin, with fetch(..., {adAuctionHeaders: true}), the Ad-Auction-Signals header gets parsed as JSON to provide the signals.
 

If so, any more details on that header? What would be the header name? What payload sizes should we expect for the header's value? In what conditions will it actually be processed?

The name of the header is Ad-Auction-Signals, as mentioned here in the explainer: [0]. Currently, the payload size is limited to 1kb [1], but we’re considering increasing that to 10kb based on feedback. When Chrome conducts a Protected Audience auction, it processes any received Ad-Auction-Signals headers whose adSlot matches that of the auction.  The header contains JSON that dictates which signals are sent to which auction participants.


[0] https://github.com/WICG/turtledove/pull/695/files#diff-d65ba9778fe3af46de3edfce2266b5b035192f8869280ec07179963b81f4e624R465


[1] https://source.chromium.org/chromium/chromium/src/+/main:content/browser/interest_group/ad_auction_url_loader_interceptor.cc;l=195;drc=dcd52bb9a48216858a950b919383c44a290273f7

Thanks for the explanation - what's preventing https://github.com/WICG/turtledove/pull/695 from landing? It seems rather old (and references stuff that no longer exists, like `X-FLEDGE-Auction-Only`. (It also doesn't seem to define any error-handling for parsing the JSON that a server returns, which would be good to do.)
I maybe have just been confused. I'm not sure if 695 is intended to land, beyond 771 and 774, both of which have much more recent activity.

Caleb Raitto

unread,
Sep 11, 2023, 6:29:38 PM9/11/23
to blink-dev, Mike Taylor, Yoav Weiss, Paul Jensen, Caleb Raitto

Hi Mike,


Pull request 695 is the change to update the explainer to describe the new header-based directFromSellerSignals, whereas 771 and 774 are for the spec changes.


The explainer change describes usage of the new API and provides context for the differences between header-based and the prior bundles based versions of directFromSellerSignals, whereas the spec change describes how to implement the header-based version.


We intend to land all 3 pull requests.


Thanks,

-Caleb

Mike Taylor

unread,
Sep 15, 2023, 4:01:05 PM9/15/23
to Caleb Raitto, blink-dev, Yoav Weiss, Paul Jensen

Thanks, LGTM1 pending the PRs landing.

Yoav Weiss

unread,
Sep 16, 2023, 12:52:57 AM9/16/23
to Mike Taylor, Caleb Raitto, blink-dev, Paul Jensen
On Fri, Sep 15, 2023 at 10:00 PM Mike Taylor <mike...@chromium.org> wrote:

Thanks, LGTM1 pending the PRs landing.

On 9/12/23 12:29 AM, Caleb Raitto wrote:

Hi Mike,


Pull request 695 is the change to update the explainer to describe the new header-based directFromSellerSignals, whereas 771 and 774 are for the spec changes.


The explainer change describes usage of the new API and provides context for the differences between header-based and the prior bundles based versions of directFromSellerSignals, whereas the spec change describes how to implement the header-based version.


We intend to land all 3 pull requests.


Thanks,

-Caleb

On Monday, September 11, 2023 at 11:18:26 AM UTC-4 Mike Taylor wrote:


On 9/11/23 12:55 PM, Mike Taylor wrote:

On 9/7/23 6:00 PM, Caleb Raitto wrote:

Hi Yoav, some responses inline:

On Wednesday, September 6, 2023 at 12:15:45 PM UTC-4 Yoav Weiss wrote:
On Tue, Sep 5, 2023 at 9:55 PM Paul Jensen <paulj...@chromium.org> wrote:

Can you clarify what this does, as the explainer is not very explain-y?

IIUC, the current flow to get directFromSellerSignals is to download a response A which contains a link to a WBN, then download the WBN and that contains the signal info.
Your proposal is to change that so that the directFromSellerSignals information would be embedded in a response header on response A?

The original directFromSellerSignals worked by downloading a response A, from the seller’s origin, that is a WBN containing several subresources that represent signals from the seller to various auction participants -- no linking was involved.


Can you outline that flow more explicitly? Apologies, but I'd like to better understand its performance characteristics.
IIUC, in both cases we have an initial page that triggers a request, where in one that request is to a WBN (using a <link> ?) and the other it's to a random resource using fetch({adAuctionHeaders: true}) ?

I guess it's unclear to me why the former would be slower than the latter, especially given the large payloads and the fact that headers can't really be compressed.


You’re correct about this header-based version of directFromSellerSignals -- when Chrome downloads a response, from the seller’s origin, with fetch(..., {adAuctionHeaders: true}), the Ad-Auction-Signals header gets parsed as JSON to provide the signals.
 

If so, any more details on that header? What would be the header name? What payload sizes should we expect for the header's value? In what conditions will it actually be processed?

The name of the header is Ad-Auction-Signals, as mentioned here in the explainer: [0]. Currently, the payload size is limited to 1kb [1], but we’re considering increasing that to 10kb based on feedback. When Chrome conducts a Protected Audience auction, it processes any received Ad-Auction-Signals headers whose adSlot matches that of the auction.  The header contains JSON that dictates which signals are sent to which auction participants.


1K header is a lot. 10KB header is... really a lot.
Have you tested that with a variety of CDNs and other intermediaries? I wouldn't be surprised if those values would break some assumptions in existing HTTP proxying software.

Also, the JSON y'all are sending doesn't seem extremely nested. Have you considered structured fields?
 
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Yoav Weiss

unread,
Sep 20, 2023, 12:53:05 PM9/20/23
to Mike Taylor, Caleb Raitto, blink-dev, Paul Jensen
LGTM2

Talking to the team, the 10K limit is Finchable, so we'd be able to lower it if this runs into issues in the field. Also presumably, having that as a limit doesn't mean most responses would actually use that.

Chris Harrelson

unread,
Sep 20, 2023, 12:54:27 PM9/20/23
to Yoav Weiss, Mike Taylor, Caleb Raitto, blink-dev, Paul Jensen
LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWyKR0oFkjZqos1SmW1-q5DQajfnjsZDeOPJBRB2j45QA%40mail.gmail.com.

Mike Taylor

unread,
Sep 20, 2023, 3:07:11 PM9/20/23
to Chris Harrelson, Yoav Weiss, Caleb Raitto, blink-dev, Paul Jensen

And gentle reminder to please land the spec PRs :)

Caleb Raitto

unread,
Sep 20, 2023, 5:00:36 PM9/20/23
to blink-dev, Mike Taylor, Caleb Raitto, blink-dev, Paul Jensen, Chris Harrelson, Yoav Weiss
Will do (once spec reviewers have approved) -- I understand your LGTM is contingent on those landing.

Thanks, 
-Caleb

LGTM3

--
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+unsubscribe@chromium.org.

Caleb Raitto

unread,
Nov 10, 2023, 4:17:32 PM11/10/23
to blink-dev, Mike Taylor, Paul Jensen, Chris Harrelson, Yoav Weiss
FYI: I merged crrev.com/c/4930438 today, which makes the implementation adopt the "LIFO" semantics requested in [0]. The spec already was written to have these semantics. As part of this, I made a small spec change (https://github.com/WICG/turtledove/pull/903) to detect and handle duplicate adSlots in responses.

(Also, the PRs mentioned by miketaylr@ above, https://github.com/WICG/turtledove/pull/771 and https://github.com/WICG/turtledove/pull/774, merged last month).

-Caleb

LGTM3

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
--
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.

Mike Taylor

unread,
Nov 13, 2023, 10:38:02 AM11/13/23
to Caleb Raitto, blink-dev, Paul Jensen, Chris Harrelson, Yoav Weiss

Thanks for the heads up. It would be nice to write WPTs for these changes (to the extent that it's possible), rather than just Chromium unit tests.

Caleb Raitto

unread,
Nov 13, 2023, 10:53:06 AM11/13/23
to Mike Taylor, blink-dev, Paul Jensen, Chris Harrelson, Yoav Weiss
Understood, will do.

-Caleb

Caleb Raitto

unread,
Dec 6, 2023, 12:07:45 PM12/6/23
to blink-dev, Caleb Raitto, blink-dev, Paul Jensen, Chris Harrelson, Yoav Weiss, Mike Taylor
To follow-up, WPT for the LIFO changes have landed: https://github.com/web-platform-tests/wpt/pull/43510

-Caleb

Understood, will do.

-Caleb

LGTM3

--
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+unsubscribe@chromium.org.

Mike Taylor

unread,
Dec 6, 2023, 1:27:10 PM12/6/23
to Caleb Raitto, blink-dev, Paul Jensen, Chris Harrelson, Yoav Weiss

Thanks Caleb!

Reply all
Reply to author
Forward
0 new messages