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 <[email protected]>
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)
<[email protected]> wrote:
On Thu, Mar 14, 2024 at 8:48 PM Paul Jensen
<[email protected]> wrote:
Contact emails
[email protected]
Explainer
Split up large trusted signals fetches:
https://github.com/WICG/turtledove/pull/1070
<https://github.com/WICG/turtledove/pull/1070>
deprectedReplaceInURN via auction config:
https://github.com/WICG/turtledove/pull/1069
<https://github.com/WICG/turtledove/pull/1069>
Specification
Split up large trusted signals fetches:
https://github.com/WICG/turtledove/pull/1065
<https://github.com/WICG/turtledove/pull/1065>
deprectedReplaceInURN via auction config:
https://github.com/WICG/turtledove/pull/1051
<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
<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 forumhere
<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
<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 [email protected].
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 [email protected].
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 [email protected].
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.
