-
Notifications
You must be signed in to change notification settings - Fork 215
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update FLEDGE.md #727
base: main
Are you sure you want to change the base?
Update FLEDGE.md #727
Conversation
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.
With may, they were leaving the door open for the implementation to have the option to coalesce as described. |
Sorry, I must be missing something, where/what is the "as described"? |
While we're on the subject: Is there any other segmenting of the KV requests? Like...by domain perhaps? Or just joined across all IGs owned by the DSP? |
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,
it issues one...
The keys are coalesced like a SQL UNION, a distinct list. |
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. |
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. |
@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? |
I didn't know I was referencing that but that is what I was looking for. Thanks. |
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". |
Isaac, friendly ping. Did you see my last comment? What are your thoughts on leaving the word "may" in there? |
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? |
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.