search

google / ads-privacy

Apache License 2.0
301 stars 53 forks source link

Augury: Ad asset fetching, storage, and timing #24

Open eriktaubeneck opened 3 years ago

eriktaubeneck commented 3 years ago

As I understand the TURTLEDOVE flow, an ad network would receive a contextless request that only includes an interest group. The ad network would respond with bid information, as well as the actual ad assets (represented as a Web Bundle.) That is cached by the browser, and used later when making a decision about displaying either a contextual ad and an interest group ad. As a list:

  1. add to interest group a. advertiser calls TURTLEDOVE api in browser b. delay
  2. request ad for interest a. browser makes contextless request bids from ad network b. ad network respond with interest group bids and and asset
  3. ad serving on publisher page load a. request contextual ads from ad network b. find eligible cached interest group ads and bid data c. compute top bid value from bidding function between interest group ads and contextual ads d. display winning ad in fenced frame
  4. report ad served via aggregate reporting API

Now, from the Augury explainer, as I understand the core difference is that step 2 is removed, and step 3 is slightly different:

  1. same as above
  2. skipped
  3. ad serving on publisher page load a. request contextual ads and augury ads from ad network b. filter augury ads down to matches with interest groups in the browser c. compute top bid value from filtered augury bids and contextual ad d. display winning ad in fenced frame
  4. same as above

The issue here is that because step 2 is skipped, the ad assets aren't cached and cannot be displayed in step 3c (for the Augury case.)

My initial understanding was that the asset would be fetched between 3c. and 3d., but this would present a timing attack. On today's W3C web-adv group, the suggestion was that the timing attack wouldn't be an issue because the assets would already be cached. I see two potential interpretations here, and both have issues:

ardianp-google commented 3 years ago

Thank you for your interest in the Augury API.

Augury API is meant to be a way to implement bidding and auction logic without changing TURTLEDOVE API. Therefore, the following quote is what we meant:

  • Step 2 isn't entirely skipped, and some request for assets for interest groups are made outside of the publisher page load.
    • Issue: Given that each interest group can have multiple campaigns and ad assets, each interest group could end up requiring a very large amount of cache space and user bandwidth, so that all (or most) possible combinations of (campaign, asset) are available later at step 3d. (This is not an issue in the original TURTLEDOVE case, because the interest group bid must make that selection at time of caching.)

Your raised issue is correct, that the browser needs to hold some creatives for each interest group. As mentioned in the explainer, we assume that “an interest group can be associated with multiple web bundles, identified by a creative ID. On-device bidding logic can choose which creative ID to show to a user”.

I think this is a similar issue with the original TURTLEDOVE. That is, in TURTLEDOVE, eligible interest group creative may be selected based on the contextual signals available only on device, and in order to ensure sufficient coverage with possible creative assets for a given interest group, the browser may still need to download all possible creatives/assets for a given interest group.

Also, we expect that the number of possible creatives to be not very large, and hence still allow reasonable usage of cache space and user bandwidth.

We welcome further discussions on this topic.