K-anon check vs. dynamic URLs

[michaelkleber]

Hello Edge folks! We're delighted to have you on board.

Can you explain a little more how you are planning to handle the combination of dynamically-generated ad URLs and checking for k-anonymity? This seemed challenging to us. https://github.com/WICG/turtledove/issues/729 offered a partial solution, but it seems like you're going farther than that, and I'd like to understand the trade-offs.

The current Protected Audience flow is:

1. IG's generateBid gets called once with the full list of available ad URLs, i.e. both k-anon and non-k-anon ads.
2. If the IG bids with one of the non-k-anon choices, then the same IG's generateBid is called a second time, but this time with only the ads that are already k-anon in its list of available ads. Now it has a guaranteed chance to bid with an ad that's over the k-anon threshold. Of course this flow only makes sense because the browser already knows (in advance of the auction) the k-anon status for every ad in the IG.

I understand that your choice to not support on-device bidding makes your life easier here because your k-anon checks are server-to-server, which makes step 1 feasible in real time. But I still don't know how you handle step 2.

[Brandr0id]

@michaelkleber our current thinking is that indeed because of the S2S aspect we can update the k-anon status in the metadata passed between the BFE and SFE/Auction TEEs. Once any dynamic URLs are provided by a buyer to be part of the auction we can lookup if they are k-anon.

Similarly the Auction/SFE can use the provided metadata to run an auction and keep track of potentially two winners (one non-k-anon and one k-anon) to be more likely to send a successful k-anon winning response to the browser. In parallel the winning ad(s) will be reported back to k-anon to potentially join. We believe this will also help with the cold-start problem for auctions and allow quicker deployment of new creatives and for auctions to see they have hit the k-anon threshold of unique clients/visibility.

[michaelkleber]

Hi Brandon! The key step I'm worried about is the Protected Audience "second chance to bid" logic:

If generateBid() picks an ad whose rendering URL is not yet above the browser-enforced microtargeting prevention threshold, then the function will be called a second time, this time with a modified interestGroup argument that includes only the subset of the group's ads that are over threshold. (The under-threshold ad will, however, be counted towards the microtargeting thresholding for future auctions for this and other users.)

Maybe you're thinking that if the bidding function gets to make multiple bids all at once, then it can just try really hard to make a bid that it thinks will be k-anon? But if that's not the idea, then I still don't understand your plan.

[Brandr0id]

When the BFE passes the set of potential creatives/IGs to the bidding service the intent is indeed that multiple bids may be returned and we will also check/add the k-anon metadata to these bids before returning to the seller. That way the scoreAd method can take these bids and make an informed decision to increment k-anon counts on the winner(s) and return a k-anon winner to the browser in the encrypted response.

[michaelkleber]

Sorry that I still haven't communicated my question successfully.

What happens if an IG's generateBid() returns only non-k-anon ad URLs?

In Chrome's approach, the IG gets a second chance to bid, with the browser infrastructure making clear which ads have passed the k-anon check. In Edge's approach, is that bidder just out of luck?

[Brandr0id]

Thanks for the clarification. Yes if the bidder ends up returning N bids which are all not k-anon none of those would win the auction and the current plan would not be to duplicate the bidding phase. We think this is okay if it is expected by the participants as in practice there is typically a contextual backup/default ad that can be rendered. Additionally, we believe the proximity to the k-anon service will aide in updating the cache to more quickly to allow new creatives that are winning to accurately reflect they are now k-anon and able to be rendered.

If in practice during trials of the API we do experience non-ideal behaviour we are open to feedback and adjusting the flow to ensure successful outcomes while maintaining privacy and performance characteristics; this could include importing the well-worn ad tech notion of a default creative as part of the auction.

Also CC: @thegreatfatzby

[michaelkleber]

Got it, thank you.

This is a very interesting alternative, which we didn't really consider since the real-time k-anon check is not viable for on-device auctions. We like the notion of making multiple bids, and it would be great if that's sufficient to not need to worry about the dedicated k-anon duplicate bidding phase.