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/CAOMQ%2Bw8bE9x06%3DQrDCjr082hkqbG_UT5-NvVm-co5Kse-AqO%2Bw%40mail.gmail.com.
