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 > > deprectedReplaceInURN via auction config: > https://github.com/WICG/turtledove/pull/1069 > > > Specification > > Split up large trusted signals fetches: > https://github.com/WICG/turtledove/pull/1065 > > deprectedReplaceInURN via auction config: > 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. > > 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 > > > 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 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: > > 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 > > > 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/CAOmohSLVNpAoUBQUwiDp3EJ3AF5WPAycWCgkENP3SOLXq6nfpA%40mail.gmail.com.
