WICG / turtledove

TURTLEDOVE
https://wicg.github.io/turtledove/
Other
519 stars 219 forks source link

trustedBiddingSignals Request Flexibility on Query, Headers, Etc #756

Open thegreatfatzby opened 1 year ago

thegreatfatzby commented 1 year ago

Digging through the code level spec, I see that trustedBiddingSignalsUrl cannot have a query component (bullet 5.12 section 2.1), and that that and others cannot have a fragment (bullet 5.11 same section).

I'm guessing this is to make the final URL formation easier when hitting the KV server (although mildly curious if there's other reasons). The fragment I can't see being too constraining; the query limitation I'd like to understand better.

I can see us wanting to pass additional static-across-requests-but-changing-across-users-or-from-time-to-time things in as query params such as a request version, a sharding key, or some other request parameterization. We can add values via the trusted bidding signal keys and encode things in there (we can also add to the path but then that would mess with the KV server coalescing), but I'm not sure why we wouldn't allow a bit more flexibility in the URL formation to accommodate existing systems and code, frameworks that like things a certain way, etc. I can see this becoming more meaningful as B&A gets more usage and clients do clever things with their topology.

So to make this into a request, I'll ask to allow more flexibility in the request formation (query params, headers) to allow for easier/faster/performant integration with existing systems. Is this constraint necessary?

JensenPaul commented 1 year ago

I don't know the original reasons, but my gut reaction is to not allow query params for a couple reasons:

  1. If the base URL had a query component, the browser would have to merge this with query component that gets attached during the fetch, as described here, and this could be annoying to join and merge with an existing query component (e.g. duplicate query params, differently ordered query params etc).
  2. Allowing query components or fragments encourages different trustedBiddingSignalsURLs per interest group, which can impede coalescing the fetches at auction time which could impact performance of the auction and increase QPS on the server. I talk more about this here. Some browser optimization may be opportunistic in when they fire and only fire if trustedBiddingSignalsURL and biddingLogicURL match between interest groups.
peiwenhu commented 1 year ago

Even if this may be allowed during the BYOS phase it would certainly not be allowed when trusted server is required to replace BYOS servers for privacy reasons as the query params or headers would leak user information.