Hi Brad! We definitely intend for TURTLEDOVE to allow the kinds of allow-lists and block-lists that you're describing.

Lists of domains and lists of topics for any particular ad can be included in the ad signals in the interest-group response where that ad gets served. If a raw list of required/forbidden items is prohibitively large, then something like a Bloom filter could be a good way to save space. But if your DSP evaluates each page and has a list of, say, 10,000 topics that it lets buyers block on, then sending the publisher-selected blocklist as a bitvector takes <2Kb of space, nothing to worry about.

As you point out, the publisher's SSP and the advertiser's DSP need to cooperate so that both the buyer and seller can have appropriate control over the selection process, comparably to RTB today. I have a few sentences about that in the On-Device Auction section; see the paragraph beginning "In the case where the interest-group response came from some other ad network..."

I haven't tried to dictate any details of how this arrangement would work — it seems to me that that's really something for the ads industry to hash out. I can imagine a few different answers that are all just fine as far as the browser is concerned. If it's more convenient for the browser to run multiple JS decisions functions, to support both buyer and seller needs, that's an easy change.

@michaelkleber - In terms of black/whitelisting and efficiently encoding them that would entail that the different parties would agree on some sort of dictionary that is globally aligned and backing these bit-vectors which are then leveraged within the bidding logic(s).

I would assume you'd see the details of this to be worked out by the digital marketing industry to agree upon via other bodies / standardisation processes outside of W3C.

It seems to me that there are two possibilities: Either (1) there is some agreed-upon dictionary, as you say, or (2) the DSP who served the ad also provides its own signals to the in-browser auction.

In case 2, the JS doing the bidding is owned by the same people who create all the signals that feed into that JS's execution. So there is no need for standardization on what signals look like or what they mean; every DSP could come up with their own answers.

Also in case 2, there does need to be some agreement on how the signals are transported from the DSP to the browser, through some RTB-like process. That is absolutely something that the digital marketing industry would need to work out in some other body.

Agree on case 2) - that would assume though that the same DSP is involved in both the Interest Group Request as well as the 1st-Party RTB like request if we call it like that (which has access to the actual URL and can map that to a brand-safety signal)

Could be different advertisers in both requests, but in case it is a different DSP one would need a generic way of doing it, which still could be standardised - case 1)

Hmm, even without standardization, this still seems like a solvable problem to me.

As the 1p-and-contextual request makes its way through the RTB system, lots of different DSPs get an opportunity to bid on the impression. Suppose each DSP sends the exchange both a bid and its own brand safety signals. Then there's an auction and only a single winning 1p-and-contextual ad gets returned to the browser — but the exchange could send to the browser the brand safety signals from all of the bidders, right?

Then each interest-group-targeted ad in the browser gets to run its own bidding JS, which was sent by the DSP who served the ad. And we can let that JS get access to that same DSP's signals.

I suppose it's possible that some DSP has an interest-group ad that was previously stashed in the browser, but for whatever reason that DSP doesn't get called as part of the RTB fan-out for this particular 1p-and-contextual auction. Then the corresponding ad could just decline to bid. But in today's world, that DSP would never get a chance to buy on this impression either, right? So it doesn't seem like a huge change.

Or an interest-group ad could be willing to fall back to case 1 when that happens — there could be some industry-standard signals that the publisher's ad network provides, and when the on-device bidding JS doesn't have its own DSP's signals, it could consume the standardized signals, treat them however skeptically it wants to, and choose to buy anyway.

If this all seems reasonable, then I'd be happy to push this description of how stuff could work into the explainer itself.

I do believe that with coordination between DSP and SSP a solution could be worked out to solve for whitelisting / blacklisting. I am still concerned about the amount of data needed to be shipped to the client which, as you point out, is likely not problematic if there are only a small number of ads cached locally, but could balloon if unrestricted.

There are a few details that might help clarify if sufficient optimization is possible:

1. Will the number of cached ads be restricted? If so, what will the maximum number be and/or how will that number be chosen?
2. Will cached ads be expired? Will expiration be managed by the ad or by the browser?
3. Will a shared store be available such that multiple cached ads sharing the same whitelist/blocklist data could prevent duplicating data locally?

This sounds reasonable, the 1p-and-contextual request would need to receive a per DSP brand safety signal and inject it into the sandbox (this requires some work on the RTB protocol). In fact the SSP on the publisher side would manage that I assume.

I think the tricky bit that the DSP vendors need to look into is the granularity of white/blacklists as they are used today to my understanding. Having that said the DSP would only need to construct a signal that covers all the Interest Group based campaigns that it manages, maybe there is a clever encoding for that.

The SSP won't know which DSPs (they work with thousands) might have ads cached on the client, so it may not make a bid request to the given DSP for a given 1p-and-contextual request.

To ensure more effective utilization of cached ads, SSP or publisher contextual data would likely be used with perhaps some collaboration with DSPs for custom contextual signals provided asynchronously and included on relevant responses. Real time contextual signals from all but the largest DSPs would be unreliable.

I agree that this seems to all turn into a question about efficiency of utilization of cached ads. As we discussed in #14, the possibility of an SSP deciding not to call out to a DSP for this particular request seems similar to today's world — without a cached ad, the DSP would likewise not get a chance to buy this particular inventory. The difference from today is that there is some resource cost even when the DSP never gets to show their ads, which everyone (browsers and servers alike) would prefer to avoid.

The quantitative questions that @brodrigu asks above are all good ones to think about in that context, and are the sort of questions we will need to answer in order to ship TURTLEDOVE to production. We (Chrome) would generally try to pick values based on observing real-world usage: How often do ads win many times? How many interest groups is a browser usually in? What fraction of ads come from each of the targeting types?

This isn't something that Chrome can start measuring today, since right now all targeting types are indistinguishable to the browser. But modern browsers already maintain a large number of caches that we optimize for various performance metrics and resource trade-offs. So this is a comfortable space for browsers to optimize over time.

Closing this issue as it represents past design discussion that predates more recent proposals. I believe some of this feedback was incorporated into the Protected Audience (formerly known as FLEDGE) proposal. If you feel further discussion is needed, please feel free to reopen this issue or file a new issue.