On Wed, Mar 20, 2024 at 2:02 PM Yoav Weiss (@Shopify)
<yoavwe...@chromium.org> wrote:
On Thu, Mar 14, 2024 at 8:48 PM Paul Jensen
<pauljen...@chromium.org> wrote:
Contact emails
pauljen...@chromium.org
Explainer
Split up large trusted signals fetches:
https://github.com/WICG/turtledove/pull/1070
<https://github.com/WICG/turtledove/pull/1070>
deprectedReplaceInURN via auction config:
https://github.com/WICG/turtledove/pull/1069
<https://github.com/WICG/turtledove/pull/1069>
Specification
Split up large trusted signals fetches:
https://github.com/WICG/turtledove/pull/1065
<https://github.com/WICG/turtledove/pull/1065>
deprectedReplaceInURN via auction config:
https://github.com/WICG/turtledove/pull/1051
<https://github.com/WICG/turtledove/pull/1051>
Summary
These are the changes to Protected Audience that we’d
like to ship:
Split up large trusted signals fetches:
During Protected Audience auctions the browser fetches
real-time signals from buyers' and sellers' key-value
servers. These fetches are currently HTTP GET requests
with URLs that the browser assembles by concatenating
several individual requests together. The URLs can grow
larger than some HTTP servers support resulting in
failing requests and reduced website ad revenue. The
proposal here is for buyers and sellers to specify the
maximum size of these URLs and for the browser to split
large requests into chunks no larger than the specified
maximum size.
If I understand correctly what y'all are trying to do here,
you're trying to effectively recreate with GETs what
should've been a POST.
Is the reasoning for that outlined somewhere?
POSTs have many advantages over GETs when transferring large
amounts of data to the server. Most importantly, they tend
to actually pass through. Beyond that, the data is not
typically saved to logs (whereas URLs often are). Finally,
in theory POST request bodies could be compressed, although
that's rarely used in practice.
You make good points about POST vs GET usage here, and we agree
with most of them. We in fact announced our plans to transition
the Protected Audience trusted signals fetches to POST and add
compression
<https://github.com/WICG/turtledove/commit/d58a984d9088978b9ee9012a8ab869addfea2d1a>more
than a year ago in our version 2 of the API. GET, however, has
the huge advantage of facilitating HTTP caching in the browser
while it’s proving very complicated to architect and implement
caching for the trusted signals fetches when POST is used.
We’re making good progress towards this new caching and protocol
version 2, but it’s going to take more time, so splitting up
trusted signals fetches is necessary until version 2 is ready.
deprectedReplaceInURN via auction config:
Protected Audience ad selection auctions return an
opaque URN or FencedFrameConfig that can be used to
display the selected ad creative. To facilitate
adoption, until at least 2026, we agreed to support an
API called deprecatedReplaceInURN() that allows
replacing macros in the ad creative URL with information
from the page where the ad will be displayed. This is
useful for better supporting video ads, some brand
safety checks, and other use cases. Today, this API’s
ergonomics are not great for component sellers (i.e.
sellers other than the top-level seller). We're making
it possible for all component sellers to be able to
specify macro replacements in their auction configs.
Blink component
Blink>InterestGroups
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EInterestGroups>
TAG review
For Protected Audience:
https://github.com/w3ctag/design-reviews/issues/723
<https://github.com/w3ctag/design-reviews/issues/723>
TAG review status
Completed for Protected Audience, resolved unsatisfied.
Risks
Interoperability and Compatibility
Both features represent optional new behavior that
shouldn’t break existing usage.
Gecko & WebKit: No signal on parent proposal, Protected
Audience. Asked in the Mozilla forumhere
<https://github.com/mozilla/standards-positions/issues/770>,
and in the Webkit forum here
<https://github.com/WebKit/standards-positions/issues/158>.
Web developers:
Split up large trusted signals fetches: 4+ companies
requesting on Github issue
<https://github.com/WICG/turtledove/issues/767>.
deprectedReplaceInURN via auction config: 4+ companies
requesting on Github here
<https://github.com/WICG/turtledove/issues/286#issuecomment-1910551260>and
here
<https://github.com/WICG/turtledove/issues/931#issuecomment-1911192809>.
Debuggability
Both of these settings and the resulting network
requests are visible in DevTools.
Will this feature be supported on all six Blink
platforms (Windows, Mac, Linux, ChromeOS,
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 have started web-platform-tests and plan to land them
for both features shortly.
Flag name on chrome://flags
None
Finch feature name
kFledgeSplitTrustedSignalsFetchingURL,
kEnableDeprecatedRenderURLReplacements
Requires code in //chrome?
False
Estimated milestones
Shipping on desktop and Android in M123.
Anticipated spec changes
None
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5619781148606464
<https://chromestatus.com/feature/5619781148606464>
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.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABQTWr%3DJ5_fT2EQc-YyqfYL5-GZdnj12WpApCUVD6U3eC7D6DA%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABQTWr%3DJ5_fT2EQc-YyqfYL5-GZdnj12WpApCUVD6U3eC7D6DA%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/CABQTWrnOhtvX-CQDX_NqQSBB0OfoFWWmu4d9tGg-KpVo7UkeUg%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABQTWrnOhtvX-CQDX_NqQSBB0OfoFWWmu4d9tGg-KpVo7UkeUg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
