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