LGTM3

On 8/7/24 11:45 AM, Chris Harrelson wrote:
LGTM2

On Wed, Aug 7, 2024 at 8:25 AM Yoav Weiss (@Shopify) <yoavwe...@chromium.org> wrote:

    LGTM1 % spec nit

    On Wednesday, July 31, 2024 at 6:38:43 PM UTC+2 Paul Jensen wrote:

        On Friday, July 26, 2024 at 5:28:22 AM UTC-4 Yoav Weiss wrote:

            On Mon, Jul 22, 2024 at 5:26 PM 'Maksim Orlovich' via
            blink-dev <blink-dev@chromium.org> wrote:

                Note: https://github.com/WICG/turtledove/pull/1230
                <https://github.com/WICG/turtledove/pull/1230> is an
                updated link for the second spec clarification pull
                requests, and the first one of the two has landed.


                On Fri, Jul 19, 2024 at 4:40 PM Paul Jensen
                <pauljen...@chromium.org> wrote:


                    Summary

                    This feature allows the Protected Audience (PA)
                    API to fetch real-time bidding and scoring signals
                    from origins other than the origin of the buyer
                    and seller's scripts. This is done by enabling
                    CORS on these requests and some additional checks
                    and requirements, and changes to prevent misuse.


            Can you expand on the "changes to prevent misuse" part?
            What misuse are we concerned with? What have we done to
            avoid it?

        Previous to this proposal, the trusted signals were required
        to come from the same origin as the bidding or scoring script
        that processed them, and the script could safely assume that
        the signals it received were from its same origin.  With this
        new ability to fetch them from another origin we wanted to
        avoid a couple forms of misuse:

        1.

            unintentional/accidental misconfiguration where the
            trusted signals origin (specified in the interest group or
            auction configuration) could now be a different origin but
            the script processing these signals might not be updated
            to understand this or process signals from another origin, or

        2.

            intentional/malicious misconfiguration where someone might
            have changed the origin of the trusted signals unbeknownst
            to the script processing them.  This isn’t possible for
            trusted bidding signals as the interest group (where the
            trusted bidding signals URL is specified) is only settable
            from same-origin contexts.


    That last part is using AsyncTask
    
<https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/probe/core_probes.h;l=83?q=AsyncTask%20f:blink&ss=chromium>?
    Is that well-defined in the PR? I'm not sure we have a strict
    concept of "context" in the platform today.
    TaskAttribution
    <https://wicg.github.io/soft-navigations/#sec-task-attribution-algorithms> 
took
    a stab at that and AsyncContext
    <https://github.com/tc39/proposal-async-context> is another, but I
    guess that making that implementation-defined
    <https://infra.spec.whatwg.org/#implementation-defined> would work
    as well for now.

        1.

              Auction configurations (where the trusted scoring
            signals URL is specified) don’t have the same same-origin
            setting requirements, but this is why this proposal
            requires the scoring script to include the
            Ad-Auction-Allow-Trusted-Scoring-Signals-From response
            header which lists allowed origins for the trusted scoring
            signals.  Misconfiguration here could look like a scoring
            script allowing two trusted scoring signals origins, and
            someone switching between these allowed origins unexpectedly.

        To prevent these misconfigurations, we changed how the trusted
        signals are passed to the scripts: they are passed in a new
        parameter so as not to be confused with the previously
        always-same-origin signals parameter, and this new parameter
        is a map from the origin of the signals to the signals
        themselves.  This was discussed as risk #2 in my GitHub post
        <https://github.com/WICG/turtledove/issues/813#issuecomment-2003946175>.

        The Ad-Auction-Allow-Trusted-Scoring-Signals-From header also
        prevents the trusted scoring signals request from being sent
        to unexpected origins.

-- 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/f3759194-8de5-45d1-9c96-6c4421194337n%40chromium.org
    
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f3759194-8de5-45d1-9c96-6c4421194337n%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/CAOMQ%2Bw84wWViN6yzFAYjTA3BVp%3DSsRxo%2BHg3%2BBdAHT2Z4F4irQ%40mail.gmail.com <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw84wWViN6yzFAYjTA3BVp%3DSsRxo%2BHg3%2BBdAHT2Z4F4irQ%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/f0e17fd5-e41c-4256-a6bd-f6e4fb68221d%40chromium.org.

Reply via email to