Update FLEDGE.md

[thegreatfatzby]

Looking for clarity disguised as commit, not clear if this is done automatically or if the IG owner needs to take some action (i.e. include interestGroupNames as a key in the trusted keys or some such.

[dmdabbs]

The requests may be coalesced (for efficiency)...

With may, they were leaving the door open for the implementation to have the option to coalesce as described.

[thegreatfatzby]

Sorry, I must be missing something, where/what is the "as described"?

[thegreatfatzby]

While we're on the subject:
"The requests may be coalesced ... across any number of interest groups that share a trustedBiddingSignalsURL (which means they also share an owner)."

Is there any other segmenting of the KV requests? Like...by domain perhaps? Or just joined across all IGs owned by the DSP?

[dmdabbs]

Sorry, I must be missing something, where/what is the "as described"?

The paragraph and accompanying example TBS url.

In that hypothetical auction the DSP/IG owner (www.kv-server.example) has two eligible IGs, 'name1, name2', (that share the same TBS url). Instead of Chrome issuing two TBS fetches,

https://www.kv-server.example/getvalues?hostname=publisher.com&experimentGroupId=12345&keys=key1,key2&interestGroups=name1
https://www.kv-server.example/getvalues?hostname=publisher.com&experimentGroupId=12345&keys=key1,key2&interestGroups=name2

it issues one...

https://www.kv-server.example/getvalues?hostname=publisher.com&experimentGroupId=12345&keys=key1,key2&interestGroups=name1,name2

The keys are coalesced like a SQL UNION, a distinct list.
I filed a PR for the interestGroups -> interestGroupNames parameter name typo.

[thegreatfatzby]

OK, so basically any query string parameter will be merged, strings comma-concateneated, etc?

Still curious on the KV server request partitioning piece. A relevant accompanying question is if there are plans for what the ToS will be for an ad tech using these APIs but using BYOS KV server.

[thegreatfatzby]

Hey @alextcone-google not sure who the right person to ping here is, I'm quite curious to hear what technical, Terms of Service, or other limitations there will be on the concatenation of IG names across an ad techs IGs when sending the KV request to an untrusted BYOS server.

[alextcone-google]

@thegreatfatzby Concatenation of IG names across an ad tech's IGs when sent to an untrusted BYOS server is documented in our spec and explainer. Can you elaborate on what you mean by Terms of Service, or which part of it you have questions about? Are you perhaps referencing https://github.com/privacysandbox/attestation?

[thegreatfatzby]

I didn't know I was referencing that but that is what I was looking for. Thanks.

[JensenPaul]

I think the word "may" is intentional. I think the combining of trusted signals requests is an optimization, meaning it's done as a best effort by the browser (e.g. a simplistic/basic implementation may not combine any requests). I suspect there will be times when the browser is unable to combine requests, for example if the URL becomes too long for servers as described in #767. I'm okay changing the wording here to include the word "automatic" as in "the browser may automatically combine, in an effort to reduce network requests" but I think we should leave in the word "may".

[JensenPaul]

Isaac, friendly ping. Did you see my last comment? What are your thoughts on leaving the word "may" in there?

[thegreatfatzby]

Ohh OK I see, the distinction is between the current Chrome implementation and what "any device" implementing this must do to be compliant. Right?

If that is right, I should ask how you guys are thinking about what information goes in this doc...if it's just "what an implementing browser has to do to be compliant" then only "may automatically" makes sense; that said, I suspect it will be common to understand this as saying what Chrome is doing, so I'd knee-jerk say what I change it to "may automatically" with a parenthesized note about what Chrome is doing?