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/CAOmohSJ26mKapOj%3D_GEq8NC%3DcoQzdoHejQmsT_Lci4Gjow-Nzw%40mail.gmail.com.
