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). [0] https://github.com/WICG/turtledove/pull/695#discussion_r1255065849 -Caleb On Wed, Sep 20, 2023 at 5:00 PM Caleb Raitto <carai...@chromium.org> wrote: > Will do (once spec reviewers have approved) -- I understand your LGTM is > contingent on those landing. > > Thanks, > -Caleb > > On Wednesday, September 20, 2023 at 3:07:11 PM UTC-4 Mike Taylor wrote: > >> And gentle reminder to please land the spec PRs :) >> On 9/20/23 12:54 PM, Chris Harrelson wrote: >> >> LGTM3 >> >> On Wed, Sep 20, 2023 at 9:53 AM Yoav Weiss <yoavwe...@chromium.org> >> wrote: >> >>> 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. >>> >>> On Sat, Sep 16, 2023 at 6:52 AM Yoav Weiss <yoavwe...@chromium.org> >>> wrote: >>> >>>> >>>> >>>> >>>> On Fri, Sep 15, 2023 at 10:00 PM Mike Taylor <miketa...@chromium.org> >>>> wrote: >>>> >>>>> Thanks, LGTM1 pending the PRs landing. >>>>> On 9/12/23 12:29 AM, Caleb Raitto wrote: >>>>> >>>>> Hi Mike, >>>>> >>>>> Pull request 695 <https://github.com/WICG/turtledove/pull/695> is the >>>>> change to update the explainer to describe the new header-based >>>>> directFromSellerSignals, whereas 771 >>>>> <https://github.com/WICG/turtledove/pull/771> and 774 >>>>> <https://github.com/WICG/turtledove/pull/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 <pauljen...@chromium.org> >>>>>> wrote: >>>>>> >>>>>> Contact emails >>>>>> >>>>>> >>>>>> * pauljen...@chromium.org <pauljen...@chromium.org> *Explainer >>>>>> >>>>>> * https://github.com/WICG/turtledove/pull/69 >>>>>> <https://github.com/WICG/turtledove/pull/695>5 * >>>>>> >>>>>> >>>>>> 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 >>>> <https://www.rfc-editor.org/rfc/rfc8941.html>? >>>> >>>> >>>>> >>>>>> [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. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Caleb >>>>>> >>>>>> >>>>>> Specification >>>>>> >>>>>> >>>>>> * https://github.com/WICG/turtledove/pull/771 >>>>>> <https://github.com/WICG/turtledove/pull/771> >>>>>> https://github.com/WICG/turtledove/pull/774 >>>>>> <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 >>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EInterestGroups> >>>>>> *TAG review >>>>>> >>>>>> >>>>>> * The parent proposal, Protected Audience, is still pending: >>>>>> https://github.com/w3ctag/design-reviews/issues/723 >>>>>> <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 >>>>>> <https://github.com/mozilla/standards-positions/issues/770>, and in the >>>>>> Webkit forum here >>>>>> <https://github.com/WebKit/standards-positions/issues/158>. * >>>>>> >>>>>> >>>>>> * Web developers: Adtech asked for this via this Protected Audience >>>>>> Github issue >>>>>> <https://github.com/WICG/turtledove/issues/119#issuecomment-1274013176>. >>>>>> * >>>>>> >>>>>> >>>>>> >>>>>> 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 >>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>> ? >>>>>> >>>>>> >>>>>> * 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 >>>>>> <https://chromestatus.com/>. >>>>>> >>>>>> -- >>>>>> 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+unsubscr...@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 >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABQTWrkbaAuRoxPUtrQnxyS-W%3DfZjba1JN%2BHCHyLmKCKveHXOg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>>> -- >>>>>> 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+unsubscr...@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 >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5c238b79-7120-4089-a8d7-dc1e67f956fcn%40chromium.org?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>>> -- >>> 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+unsubscr...@chromium.org. >>> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWyKR0oFkjZqos1SmW1-q5DQajfnjsZDeOPJBRB2j45QA%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWyKR0oFkjZqos1SmW1-q5DQajfnjsZDeOPJBRB2j45QA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAChiYOUSDby6xUQFiyz-Q5troXvWLP0CHisJgcB%2BvaugCZVqNw%40mail.gmail.com.
