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