To follow-up, WPT for the LIFO changes have landed: https://github.com/web-platform-tests/wpt/pull/43510
-Caleb On Monday, November 13, 2023 at 10:53:06 AM UTC-5 Caleb Raitto wrote: > Understood, will do. > > -Caleb > > On Mon, Nov 13, 2023 at 10:37 AM Mike Taylor <miketa...@chromium.org> > wrote: > >> 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. >> On 11/10/23 4:17 PM, Caleb Raitto wrote: >> >> 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/df00e465-6ceb-4439-ada5-d9fd50c7c08dn%40chromium.org.
