search

WICG / turtledove

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

Appending bidding-time information to rendering urls #176

Open fabienbk opened 3 years ago

fabienbk commented 3 years ago

Hi fledgers!

The generate_bid() function is expected to output a rendering url. Do you know if these urls MUST match exactly one of the ads urls present in the interest group ?

This snippet seems to indicate that strict equality is indeed required: https://github.com/chromium/chromium/blob/master/content/services/auction_worklet/bidder_worklet.cc#L272

However, it would be very useful to augment these urls with bidding-time info, adding to their query string for instance (while the end result would be still complying with the k-anonymity constraint).

One particular use case would be to append the width & the height of the display to the final rendering url. Doing so will allow to keep the number of ads in the interest group relatively low. It's of course possible to generate all the possible urls with sizes, but that will potentially generate a lot of urls for no real gain (as many ads have a intrinsic fixed size).

brusshamilton commented 3 years ago

One of the requirements for FLEDGE to meet its privacy guarantees is that requests to non-trusted servers, such as fetching the data pointed to by the rendering URL, must happen asynchronously from the auction (hence the "two uncorrelated requests" part of the original TURTLEDOVE). In practice this means that the creative from the rendering URL and its subresources must be either retrieved well before the auction occurs and stored by the browser (such as in a web bundle) or the creative/subresource must be loaded from some trusted server (such as a trusted CDN).

Clearly when the creative is retrieved before for the auction the URL must be an exact match, since otherwise the browser doesn't have the ad. There may be more flexibility later as the spec continues development, since support for a trusted server for subresources may be required to support larger creatives (such as those with videos).

fabienbk commented 3 years ago

Hi @brusshamilton and thanks a lot for your answer!

In practice this means that the creative from the rendering URL and its subresources must be either retrieved well before the auction occurs and stored by the browser (such as in a web bundle) or the creative/subresource must be loaded from some trusted server (such as a trusted CDN).

I totally get that, but that's exactly my point : how to design urls that are built well before the actual display. Given that many ads are "sizeful" (they have a fixed size), and encode their actual size info in the url itself (explicitely or not) that means we either need:

I suggested to append the size to urls to avoid the complexity introduced by these options. But indeed, there are are solutions around it. It's a bit unclear to me what "flavour" of them Fledge designers have in mind ?

jeffkaufman commented 3 years ago

Another option with the current API is to always use an adapter. You'd use a renderUrl that didn't include size, and you'd make your server handle sizeless turtledove urls with something like:

<html>
<script>
// redirect the fenced frame to a new renderUrl that includes the observed width and height
window.location = window.location.href + `?width=${innerWidth}&height=${innerHeight}`
</script>
</html>

The downside of this approach is an extra round trip in rendering the ad.

Note that this relies on the As a temporary mechanism, we will still allow network access, rendering the winning ad in a Fenced Frame that is able to load resources from servers component of the current FLEDGE design, and so wouldn't work as a long-term approach.

fabienbk commented 3 years ago

@jeffkaufman yep that's what i meant by "internal delivery mecanism", and indeed, that relies on the temporarily relaxed rules. i'm hoping for some guidance on the long term philosophy, at least in the future :)