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 <https://github.com/WICG/turtledove/issues/1105#issuecomment-2043779939>.
On Wed, Apr 10, 2024 at 12:46 PM Alex Russell <slightly...@chromium.org> wrote: > 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/CABQTWrk%3DXb_SXNSnvYgw9yz839%2BpAfPwKNJzNdjZ0k4fc2eAXg%40mail.gmail.com.
