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
<[email protected]> wrote:
Contact emails*
[email protected]
*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 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.)
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 [email protected]
<mailto:[email protected]>.
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 [email protected].
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2b275c56-50eb-48d7-8396-0906d3c605a4%40chromium.org.
