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 On Wednesday, April 10, 2024 at 8:43:17 AM UTC-7 Daniel Bratell wrote: > LGTM3 > > /Daniel > On 2024-04-08 17:37, Yoav Weiss (@Shopify) wrote: > > LGTM2 > > On Mon, Apr 8, 2024 at 5:36 PM Mike Taylor <miketa...@chromium.org> wrote: > >> LGTM1 >> On 4/3/24 11:05 AM, Daniel Bratell wrote: >> >> Thanks, that clarifies a bit and calms my worries considerably. >> >> /Daniel >> On 2024-03-29 14:27, Paul Jensen wrote: >> >> 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 >> <https://github.com/privacysandbox/protected-auction-services-docs/blob/main/key_value_service_trust_model.md#:~:text=the%20return%20value%20for%20each%20key%20will%20be%20based%20only%20on%20that%20key>. >> >> >> 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. >> >> On Wed, Mar 27, 2024 at 12:21 PM Daniel Bratell <bratel...@gmail.com> >> wrote: >> >>> 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 >>> On 2024-03-25 17:44, 'Paul Jensen' via blink-dev wrote: >>> >>> >>> >>> 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 >>>>> >>>>> 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 >>> <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 >>>>> >>>>> >>>>> 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/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> >>> . >>> >>> -- >> 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/c05857a0-c4b4-4623-b08f-dd4f5c95784e%40gmail.com >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c05857a0-c4b4-4623-b08f-dd4f5c95784e%40gmail.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/2f2f7173-ed35-4ce4-9362-405403dd26b8n%40chromium.org.
