clarification re: lack of support for multi-size banners

[rdgordon-index]

Multi-size banner impression opportunities are extremely common, and can represent the majority of the banner ad slots from browser-based header bidding integrations; in fact, the most basic example in the Prebid.js docs lists two multi-size banner ad slots.

The soon-to-be-merged #417 brings size awareness to PA API; #312 (comment) has the specifics, but in short, there is now the ability to request a particular size in an auctionConfig and to associate renderURLs with optional dimensions at IG join time.

This was done primarily to address the use case noted in #311 -- responsive ads shouldnl't require distinct renderURLs -- however, the underlying issue is the multi-size banner ad slot itself.

The problem is multi-faceted:

• As per the PR, while the size is communicated to the buyer, there is no required to bid with a creative of that size (emphasis added) -- and scaled/resized creatives are not acceptable to publishers:

Bidders inside the auction may pick a different content size for the ad, and that resulting size will be visually scaled to fit inside the element's container size.

• the auctionConfig for the size the PA auction doesn't map directly to the size of the contextual auction -- so it's not clear how the top-level seller would 'choose' one of the sizes in the GPT ad slot definition just for the PA auction
• this lack of signal gets complicated when considering A/B testing for a given ad unit path, since there's also no defined mechanism for signalling this choice to the contextual auction in a consistent way to component auction participants
• while scoreAd would have access to the width and height from generateBid alongside the renderURL, there's no way for these dimensions to visible to reportResult; as mentioned in the PR (emphasis added):

  The renderURL can be included since it has passed a k-anonymity check. Because renderSize will not be included in the k-anonymity check initially, it is not included in the browser signals

Can we get additional clarification on how we'll be able to ensure that we can run, score, and report on multi-slot auctions via PAAPI in a privacy-first model?

[shivanigithub]

cc @gtanzer

[gtanzer]

My understanding is: you are asking about the ability to run auctions where multiple potential sizes are passed in, and then the auction runs, and then one of those sizes is returned from the auction in a way that is visible to the publisher (so that they can adjust the layout of the page).

This has never been possible with Protected Audience for privacy reasons, namely that the size returned from the auction would communicate cross-site data to the publisher. PA returns an identifier that represents the winning ad opaquely precisely so that the publisher cannot learn anything about the result of the auction (with the exception of the known "one-bit leak" in the current design, which tells you whether an ad won the auction at all).

This is unrelated to the recent size changes, which make size options more flexible, since previously there was a list of only ~15 ad sizes you could use vs. now you can pick any size, and now you can also have fallback ad sizes win the auction and be loaded at that desired size (but with visual scaling to fit the size the publisher set, which is obviously undesirable).

Please let me know if I misunderstood your question, or if you are asking about a use case that is more restrictive in a particular way so that it could still be made private. For example, if you wanted to choose between ad sizes before accessing interest group data (e.g. based on publisher signals, real-time signals not based on interest group data, etc.), then it would be private for the publisher to do that because it doesn't depend on cross-site data. (And you could already do that before calling Protected Audience, right?)

[eroncastro]

Hi @gtanzer

My understanding is: you are asking about the ability to run auctions where multiple potential sizes are passed in, and then the auction runs, and then one of those sizes is returned from the auction in a way that is visible to the publisher (so that they can adjust the layout of the page).

That's something ad servers already provide, helping increase inventory impressions per position, and make ads UX consistent. Shouldn't privacy and UX walk together?

This has never been possible with Protected Audience for privacy reasons, namely that the size returned from the auction would communicate cross-site data to the publisher. PA returns an identifier that represents the winning ad opaquely precisely so that the publisher cannot learn anything about the result of the auction (with the exception of the known "one-bit leak" in the current design, which tells you whether an ad won the auction at all).

What if the ad scripts on the host page run N separate auctions with N different requestSize properties for a given position? Wouldn't this process make the size available to the publisher? How is this different from making the size available through FencedFramedConfig?

For example, if you wanted to choose between ad sizes before accessing interest group data (e.g. based on publisher signals, real-time signals not based on interest group data, etc.), then it would be private for the publisher to do that because it doesn't depend on cross-site data. (And you could already do that before calling Protected Audience, right?)

Given the inventory availability, it also makes sense to determine the size during the auction, since a DSP just needs to know the compatible sizes and could obtain in real-time which ad is available for delivery, allowing them to better rotate creatives.

[thegreatfatzby]

Background Terms

When we've been talking about this internally we've split 4 functions out:

1. The need for the seller to communicate acceptable sizes to the buyer.
2. The need for the buyer to communicate the size of a bid to the seller.
3. The need for the seller to size the iframe/FF appropriately.
4. The need for the buyer/seller to know the delivered ad size.

Publisher Needing to See Ad Size in Top Level Frame?

@gtanzer I'm not sure that's needed to accommodate multi-size ad slots. I wonder if I'm missing something, because with the current changes in the PR I think we're pretty close here. I think with some reasonable restrictions the worst-case of highly precise sizes being used to micro-target/re-identify would be avoided once the k-anon restrictions are added in Chrome 116.

Why not this?

Modify auctionConfig.requestedSize to allow a list of the same w/h objects, maybe with some reasonable limit. Those are communicated to the buyer, and the buyer returns the renderSize as now.

renderSize is not put into the browserSignals for reportResult or reportWin if it's not k-anon, but it can't win anyway once the k-check is added. (Maybe there's something interesting here with buyer/seller reporting signals, but let's go with easy case here). So, in theory, at that point it's only in browserSignals if it won, and if it won it's in browserSignals.

The width and height are set in the FF/iframe based on the final renderSize rather than requestedSize. The publisher can choose to allow only-exact size matches or not.

This would accommodate all four of the needs above but still provide the same level of k-check we get now; in particular, in the interim period with iframes and Event Level Reporting, we don't leak anything new, and then when we go to agg/FF, no new leaks are there either.

...right? Is the lack of sleep catching up with me?

Rescaled Ads

@rdgordon-index as to your comment that this isn't acceptable to publishers, I'd think the response here would be something like "the API won't enforce that but a publisher's ad tech can in scoreAd by ranking a non-exact-match as score<0". Would that work? Or do you think the API as a whole should disallow it?

[michaelkleber]

Hi folks,

The privacy issue here, as Garrett pointed out, is that the change you're asking for would be a way for the auction to leak out some of the secret cross-site information that is stored in an Interest Group. We want to go the opposite direction and reveal less of that information. Indeed we want to reveal just a single bit of information, the answer "Did the auction have any winner at all?", and eventually not even leak that.

[thegreatfatzby]

@michaelkleber I'm a little unclear, are you responding to my "why not this?"? If we think about FF, Event Reporting, and others, as a fixed set of Privacy Impacting features Ft that will be fixed at t1=2024, t2=2025, etc, but modified over time, I'm actually not clear why allowing the requestedSizes to be an array, and have the winning renderSize that passed k-anon go into the macro and impact FF size as now, adds marginal privacy leak over F at any given t.

[michaelkleber]

Because all of the other information you are talking about gets included in reporting, while the size of the ad gets revealed by rendering. We can make reporting have better privacy over time. Rendering cannot be aggregated or noised or delayed or etc; there are no tools to protect that information.

[thegreatfatzby]

Perhaps a minor implicit thing I'm thinking: what about in the case when renderSize, which must pass k-anon, is required to be an exact match of one of the requestedSize(s)? In that case it would come through reporting as well, so what's net new?

[thegreatfatzby]

I suppose that depends in part on the answer to my question here. :)

[thegreatfatzby]

Also I should say outloud, there is theoretically marginal value if the width/height are used to size the iframe but not reported.

[michaelkleber]

Sorry that I was too terse in my last answer.

The difference between "size appears in reporting" and "size varies during rendering" is indeed very large.

Information that appears in reporting is made available at the event level for now, but eventually that will no longer be the case. The genuinely private future of the Protected Audience API is one where all reporting happens in aggregate, and it is no longer possible to know which ad was shown on which page view. Obviously there is a lot more work needed to get to that point, but the API was designed to be compatible with this eventual goal.

Variable-sized ad slots, with the choice of size happening inside the PA auction based on what IGs a person is in, would be a whole different ball game. That would be an API design for which it is impossible to ever eliminate event-level information leakage. There is no way to prevent the surrounding web page from knowing what size the ad rendered at, and therefore there is no way to allow the size to vary based on ad tech logic with access to cross-site information.

[thegreatfatzby]

I'm still not sure I'm quite seeing it, I agree with all the things you say but then am not getting the final link. Perhaps it's a problem of a very slight misunderstanding of the goal.

First, Minor Clarification

When you say: therefore there is no way to allow the size to vary based on ad tech logic with access to cross-site information do you mean therefore there is no way to allow the size to vary based on ad tech logic withOUT access to cross-site information i.e. that the publisher would have to learn the size, which at that point means the publisher knows something about the advertisers decision?

Points of Agreement

• There is no way to prevent the surrounding web page from knowing what size the ad rendered at true
• therefore there is no way to allow the size to vary based on ad tech logic withOUT access to cross-site information true
• Information that appears in reporting is made available at the event level for now, but eventually that will no longer be the case understood, this is what I was trying to get at with the Ft thing ^.
• genuinely private future of the Protected Audience API aligned and want that
• Obviously there is a lot more work needed to get to that point understood
• but the API was designed to be compatible with this eventual goal aligned

Disconnect

So I think where I'm struggling to follow is all that leading to Variable-sized ad slots, with the choice of size happening inside the PA auction based on what IGs a person is in, would be a whole different ball game.

I wonder if this is related to some of what I tried to parse out in #846 , in particular the nuance of mixing cross domain data that is k-anonymous. It's a bit different in this case but maybe rooted in the same thing.

Maybe I'm Not Understanding the Constraint?

Maybe the difference is I keep basing my thinking on the north star of "prevent re-identification across contexts", but Privacy Sandbox is "thinking" of the north star as "partitioning of the internet, i.e. no cross domain information". If "re-id" is the north star, then the publisher learning that the iframe is 300x250 instead of 728x90 can be ok if at least K people have had the same rendering; however, if it's the "partitioning", then it trivially fails.

Is that it?

Hypothetical

Perhaps let me tease this out a hair more with a silly example.

We make a new element, TwoSizedFencedFrame, which can only ever be 300x250 or 728x90. For a renderURL to render the tuple (renderURL, size) must be jointly k-anon. Event level reporting has been slayed so we're no longer sending event-level-data-with-infinite-degrees-of-freedom. Let's even add some non-determinism, and say that 1% of the time when a renderUrl and size is chosen, a PSA of that size is shown instead.

Different ballgame?

[thegreatfatzby]

@michaelkleber hopefully qq you could answer w/o going through all the things: is this previous thread representative of the attack you were describing Wednesday WICG call?

[michaelkleber]

Yes sure, that previous issue is the same idea, thanks for saving me from writing a new explanation.

But! Supporting multi-sized banners would make things worse in two ways:

1. It would increase the leakage rate. If there are 15 different possible banner sizes, then an auction leaks one of 16 possible outcomes, rather than leaking one of two.
2. We know how to fix the 1-bit leak! It's hard — it requires all ads to use Fenced Frame rendering and aggregate reporting, not just ads from PA auctions. But at least we know what is required. If we switch to multi-size banners then we know the leak becomes impossible to fix.

The Protected Audience API won't have perfect privacy initially, but we have a path towards fixing its remaining gaps. With multi-size banners we'd be stuck on a bridge to nowhere.

[thegreatfatzby]

Thanks @michaelkleber , read through it once but I'll need to do a few passes. I do think I may need to ask for a little more hand holding in fully grokking this, but I'll try to get a bit further on my own.

Only One Bit?

I think where my brain is getting stuck here is that we refer to a "one bit leak", but it seams that phrasing is perhaps nomenclature known to many but misleading to someone like me who is learning about this and is not trained-in/good-at thinking like a black hat.

Am I right that when we say "one bit leak", or more accurately "a one bit leak can lead to a 32 bit ID being known in N rounds, N >= 32" what we're actually saying is "if one bit is leaked per round AND we can assert some other things, then it can lead to said ID re-construction"? In other words, the "one bit leak" must be accompanied by some other condition, or bits of information, no?

I'm not trying to be pedantic or nerd snipe here, my instinct is just that both here and in #846 there may be some combination of privacy tools we can use to get to a better place. There might be some combination of restrictions, chaff, etc, that ad tech would find preferable if we could provide important client facing features. Maybe 1% of all wins showing a PSA randomly would be better if we could get competitive exclusion, page caps, responsive ads.....

Genuinely Private Future (Genuine Privacy = GP)

Is the Fenced Frame Networking being gone, or having TEE rendering servers, required to reach GP? My understanding is that, as of now, event level reporting has a shape of a plan (move to aggregated) which I think needs a lot of digging but makes sense...the no-networking (bundles) thing seems to be on the shelf...is TEE based rendering the plan and how we get to GP?

[michaelkleber]

The jump from a repeated one-bit leak to a cross-site identifier is indeed based on the assumption that the leaked bits can be added up over time — in particular, in the Protected Audience context, that each bit can be associated with the first-party cookie (or other single-site identifier) on the site of the publisher where the ad appears.

The other protections you mention, Fenced Frames and TEEs in rendering, are similarly about breaking the connection between the chosen ad and the first party's identifier. The reason the 1-bit leak (or multi-sized banner leak) is worse is precisely because there is no way to break the connection: the page surrounding the ad inherently must necessarily know the shape of the ad rectangle.

[thegreatfatzby]

the page surrounding the ad inherently must necessarily know the shape of the ad rectangle I 100% get that.

Is it also the case though, that in the future state with no event level reporting, all FF, and TEE rendering, that the 1-bit leak would still require either a) collusion between the seller and buyer or b) the seller to effectively know enough other things about which ID, and the placement of the bits as they come in, to be able to do the reconstruction?

I'm not asking b/c I think it's not important, I think it is important, I'm just not clear if this is more trivial than I'm realizing.

[michaelkleber]

The same underlying leak could be used in a bunch of different ways. I would say your (a) and your (b) and "some clever 3rd-party script that is good at probabilistic fingerprinting" are all possible consumers of this information.

[rdgordon-index]

as to your comment that this isn't acceptable to publishers, I'd think the response here would be something like "the API won't enforce that but a publisher's ad tech can in scoreAd by ranking a non-exact-match as score<0". Would that work? Or do you think the API as a whole should disallow it?

I had missed this question earlier -- provided that generateBid() was required to provide WxH to scoreAd()`, then sellers will be able to enforce this alongside the rest of the publisher controls related to scoring individual bids, yes. However, at the moment, #417 makes this entirely optional.

[michaelkleber]

There has been some further discussion of this topic over in #211 (comment).

I am not yet sure it would work, but perhaps there is a way to enable multi-sized PA auction output if we do the following sequence of hard things:

1. Require the output of a multi-sized PA auction to render in a Fenced Frame.
2. Require the input to a multi-sized PA auction to include a contextually-targeted Fenced-Frame-rendered fallback ad of each size.
3. Allow the browser to noise the size choice, meaning that that the rendered ad might be an ad that the seller scored lower than some other differently-sized ad.

I'm absolutely not saying that I know how the noising in point 3 would work; it will require some serious thought to figure out whether this is viable.

Ad tech folks: this would be a great time to consider how valuable multi-size PA auctions would really be, since there are some substantial trade-offs to take into account.

[thegreatfatzby]

@michaelkleber can you clarify your (1) based on the other conversation: here you're saying that the multi-sized PA auction would render in a FF even if the contextual auction wins, yes? Or are you just saying for a private win?

For requiring a fallback ad for each size, that shouldn't be a problem, defaults, house defaults, and PSAs, are well worn.

Noising the size choice, or even just picking a random bid whose rank is not the top, with probability p, seems worth exploring if p can be responsive to risk. If p starts at 0.9 for a risky situation where one IG is bidding on an auction, the owner of the IG owns the auction, and one bid is submitted, but an established auction owner with a track record within-and-across-browsers of accepting diverse bids, and participating in auctions with other similar players (See PaaGERank) would approach 0, I think that could get buy in if we had multi tag and multi size.

[michaelkleber]

here you're saying that the multi-sized PA auction would render in a FF even if the contextual auction wins, yes?

Yes, that is indeed what I was saying might be needed.

Noising the size choice, or even just picking a random bid whose rank is not the top, with probability p, seems worth exploring if p can be responsive to risk.

That's an interesting idea. I absolutely do not know what kind of noising could make this work, though, and adding more design constraints to the noise approach tends to make it harder to find any solution.

[rdgordon-index]

Ad tech folks: this would be a great time to consider how valuable multi-size PA auctions would really be, since there are some substantial trade-offs to take into account.

For requiring a fallback ad for each size, that shouldn't be a problem, defaults, house defaults, and PSAs, are well worn.

Not technically a problem -- however, it has the potential to greatly diminish the value of the PA auction.

[rdgordon-index]

There was a disccusion on the recent weekly call about this issue.

[rahulkooverjee-google]

Allow the browser to noise the size choice, meaning that that the rendered ad might be an ad that the seller scored lower than some other differently-sized ad.

From the perspective of a seller, this is not desirable behavior. I believe it's important that ad auctions are deterministic and explainable. That's one of the appeals of the first price auctions that much of the ecosystem uses (including Ad Manager). It's simple - the highest bid wins.

[michaelkleber]

From the perspective of a seller, this is not desirable behavior. I believe it's important that ad auctions are deterministic and explainable.

Certainly. That's why I phrased it as "there are some substantial trade-offs to take into account." The question is not "Do you like the idea of random noise on the winning ad size?" The question is "Do you want multi-sized auctions so much that you would be willing to tolerate random noise on the winning ad size in exchange?"

[fhoering]

One option could be to handle this the same way as currencies (see long discussion in #166). So assuming that only one ad size is possible for Fledge/PA and having it either buyer decided or seller decided during the contextual call. The chosen width & height gets passed through the auction and then to reportResult/reportWin.

1. If the seller decides the ad size he sends the right format to the buyer during the contextual call
2. If the buyer decides the ad size he will choose the right ad size out of a list of ad sizes provided by the seller, send this back in the BidResponse to the seller and then this size is known and passed through the auction

Today GAM has implemented 1. And for component auctions each seller could decide if he implemented 1 or 2.

WDYT ?

[rdgordon-index]

#908 touches upon some of this complexity too re: coordination among the various PAAPI actors.