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/CABQTWr%3D9Np32YJQeMoSV6z-7mierpwAn5Wh1qFMN1OywP7OMAQ%40mail.gmail.com.
