Intent to Ship: Protected Audience: Split up large trusted signals fetches & deprectedReplaceInURN via auction config

[Paul Jensen]

Contact emails

paulj...@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.

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

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, and in the Webkit forum here.

Web developers:

Split up large trusted signals fetches: 4+ companies requesting on Github issue.

deprectedReplaceInURN via auction config: 4+ companies requesting on Github here and here.

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?

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.

[Yoav Weiss (@Shopify)]

On Thu, Mar 14, 2024 at 8:48 PM Paul Jensen <paulj...@chromium.org> wrote:

Contact emails

paulj...@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.

  

--
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+...@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.

[Paul Jensen]

On Wed, Mar 20, 2024 at 2:02 PM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

On Thu, Mar 14, 2024 at 8:48 PM Paul Jensen <paulj...@chromium.org> wrote:

Contact emails

paulj...@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.

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

[Daniel Bratell]

I can't help thinking about all the problems exposed when malicious use of Out of Sequence TCP became a thing among the evil-doers. It turned out that once you split something up, it's not always easy to put it back together again. It is a solved problem (but not quite, I found newly discovered exploits when searching for references) in network layers but only through a lot of pain and suffering.

There were the things that people with evil intent did, like sending only part of a sequence, filling up buffers that were waiting for the rest or reorder in complicated ways, or make a million small parts instead of one large. Could that become an attack surface here?

And there were the random reordering that just happened due to networks being unpredictable which servers were in general badly equipped to handle. Could reordering happen here?

Either way, I worry that this could become a source of random problems that would be hard to understand or debug. Is there any third or fourth option to consider?

/Daniel

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.

[Mike Taylor]

On 3/25/24 12:44 PM, 'Paul Jensen' via blink-dev wrote:

On Wed, Mar 20, 2024 at 2:02 PM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

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

https://github.com/WICG/turtledove/blob/main/FLEDGE_Key_Value_Server_API.md#binaryhttp-the-packaging-layer-for-http-kv-service-requests states that the method is PUT, not POST. Is that a typo? My understanding is that a response to a PUT request is not cacheable.

[Paul Jensen]

Daniel, I hear your concerns, but I should clarify that this splitting up of large requests does not do any reassembly or combining of responses, so sequencing or ordering between responses is not a concern.  The Key-Value servers answering the queries are stateless and should have no ability to associate requests.

The browser has a number of interest groups or bids that need their trusted signals fetched.  The browser can make each fetch individually or in a combined fashion, but each individual response is only supplied to the corresponding requesters; responses are not combined for requesters.

[Paul Jensen]

Mike, the second version of the Key-Value server API uses encryption on the inner request payload which means the HTTP cache won't find exact matches for requests (as encryption results in non-determinism) independent of HTTP method.  I will look at whether PUT or POST makes more sense.

[Daniel Bratell]

Thanks, that clarifies a bit and calms my worries considerably.

/Daniel

[Mike Taylor]

LGTM1

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c05857a0-c4b4-4623-b08f-dd4f5c95784e%40gmail.com.

[Yoav Weiss (@Shopify)]

LGTM2

[Daniel Bratell]

LGTM3

/Daniel

[Alex Russell]

Now that this has approval, it would be good to understand when the V2 changes to move to POST are anticipated to go out and the deprecation timline for this version.

Best,

Alex

LGTM3

/Daniel

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@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.

--
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+unsubscribe@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.

--
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+unsubscribe@chromium.org.

[Paul Jensen]

Alex,

We're currently implementing the V2 changes and have some CLs in progress to that end.  Earlier this week, we posted plans to have a prototype next quarter.

LGTM3

/Daniel

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@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.

--
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+...@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.

--
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+...@chromium.org.