Re: [blink-dev] Intent to Ship: Protected Audience: Split up large trusted signals fetches & deprectedReplaceInURN via auction config

2024-04-11 Thread Paul Jensen 
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
.

On Wed, Apr 10, 2024 at 12:46 PM Alex Russell 
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 
>> 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
>>> .
>>>
>>> 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 
>>> 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 
> 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

Re: [blink-dev] Intent to Ship: Protected Audience: Split up large trusted signals fetches & deprectedReplaceInURN via auction config

2024-04-10 Thread Alex Russell 
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  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 
>> .
>>  
>>
>> 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  
>> 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  
 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 
>>>

Re: [blink-dev] Intent to Ship: Protected Audience: Split up large trusted signals fetches & deprectedReplaceInURN via auction config

2024-04-10 Thread Daniel Bratell 

LGTM3

/Daniel

On 2024-04-08 17:37, Yoav Weiss (@Shopify) wrote:

LGTM2

On Mon, Apr 8, 2024 at 5:36 PM Mike Taylor  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

.

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
 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)
 wrote:



On Thu, Mar 14, 2024 at 8:48 PM Paul Jensen
 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

Re: [blink-dev] Intent to Ship: Protected Audience: Split up large trusted signals fetches & deprectedReplaceInURN via auction config

2024-04-08 Thread Yoav Weiss (@Shopify) 
LGTM2

On Mon, Apr 8, 2024 at 5:36 PM Mike Taylor  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
> .
>
> 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 
> 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 
>>> 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
>> 
>> 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

Re: [blink-dev] Intent to Ship: Protected Audience: Split up large trusted signals fetches & deprectedReplaceInURN via auction config

2024-04-08 Thread Mike Taylor 

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 
. 

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  
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)
 wrote:



On Thu, Mar 14, 2024 at 8:48 PM Paul Jensen
 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

more
than a year ago in our version 2 of the API. 

Re: [blink-dev] Intent to Ship: Protected Audience: Split up large trusted signals fetches & deprectedReplaceInURN via auction config

2024-04-03 Thread Daniel Bratell 

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 
. 

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  
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)
 wrote:



On Thu, Mar 14, 2024 at 8:48 PM Paul Jensen
 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

more
than a year ago in our version 2 of the API.  GET, however, has
the huge advantage of

Re: [blink-dev] Intent to Ship: Protected Audience: Split up large trusted signals fetches & deprectedReplaceInURN via auction config

2024-03-29 Thread 'Paul Jensen' via blink-dev 
Mike, the second version of the Key-Value server API uses encryption on the
inner request payload which means the HTTP cache won't find exact matches
for requests (as encryption results in non-determinism) independent of HTTP
method.  I will look at whether PUT or POST makes more sense.

On Wed, Mar 27, 2024 at 1:57 PM Mike Taylor  wrote:

> On 3/25/24 12:44 PM, 'Paul Jensen' via blink-dev wrote:
>
> On Wed, Mar 20, 2024 at 2:02 PM Yoav Weiss (@Shopify) <
> yoavwe...@chromium.org> wrote:
>
> 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
> 
> 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.
>
>
> https://github.com/WICG/turtledove/blob/main/FLEDGE_Key_Value_Server_API.md#binaryhttp-the-packaging-layer-for-http-kv-service-requests
> states that the method is PUT, not POST. Is that a typo? My understanding
> is that a response to a PUT request is not cacheable.
>

-- 
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/CABQTWrmUs7psCPzXRVER4Fuyh781YLnu6yqqH4mAbvD5Ut%3DDig%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Protected Audience: Split up large trusted signals fetches & deprectedReplaceInURN via auction config

2024-03-29 Thread Paul Jensen 
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

.
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  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 
>> 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
> 
> 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

Re: [blink-dev] Intent to Ship: Protected Audience: Split up large trusted signals fetches & deprectedReplaceInURN via auction config

2024-03-27 Thread Mike Taylor 

On 3/25/24 12:44 PM, 'Paul Jensen' via blink-dev wrote:

On Wed, Mar 20, 2024 at 2:02 PM Yoav Weiss (@Shopify) 
 wrote:


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 
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.
https://github.com/WICG/turtledove/blob/main/FLEDGE_Key_Value_Server_API.md#binaryhttp-the-packaging-layer-for-http-kv-service-requests 
states that the method is PUT, not POST. Is that a typo? My 
understanding is that a response to a PUT request is not cacheable.


--
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/4bdc9eee-c6f0-488c-9f19-ea44e19379b8%40chromium.org.

Re: [blink-dev] Intent to Ship: Protected Audience: Split up large trusted signals fetches & deprectedReplaceInURN via auction config

2024-03-27 Thread Daniel Bratell 
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) 
 wrote:




On Thu, Mar 14, 2024 at 8:48 PM Paul Jensen
 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 
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

Re: [blink-dev] Intent to Ship: Protected Audience: Split up large trusted signals fetches & deprectedReplaceInURN via auction config

2024-03-25 Thread 'Paul Jensen' via blink-dev 
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 
> 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

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
>> 
>>
>>
>> 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
>> , and in the
>> Webkit forum here
>> .
>>
>>
>> Web developers:
>>
>> Split up large trusted signals fetches: 4+ companies requesting on Github
>> issue .
>>
>> deprectedReplaceInURN via auction config: 4+ companies requesting on
>> Github here
>> 
>> and here
>> .
>>
>>
>> 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
>>

Re: [blink-dev] Intent to Ship: Protected Audience: Split up large trusted signals fetches & deprectedReplaceInURN via auction config

2024-03-20 Thread Yoav Weiss (@Shopify) 
On Thu, Mar 14, 2024 at 8:48 PM Paul Jensen  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.


>
> 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
> 
>
>
> 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
> , and in the
> Webkit forum here
> .
>
>
> Web developers:
>
> Split up large trusted signals fetches: 4+ companies requesting on Github
> issue .
>
> deprectedReplaceInURN via auction config: 4+ companies requesting on
> Github here
> 
> and here
> .
>
>
> 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
> 
> ?
>
> 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
> .
>
> --
> 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
>