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


            *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.


    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
    
<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
    
<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
    <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
            <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
            <mailto: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
    <mailto: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/db5b5d5c-7f06-4c34-9a03-6a95757261d3%40chromium.org.

Reply via email to