Does the concept of the size in the proposed change have a material impact on the behavior of the FLEDGE auction other than the substitution of macros in render URLs, and a K-anonymity check during the auction and reporting time?

That is, is there anything specific about the concept of a size that makes it worthwhile to have distinct size (comprised of width, height) semantics in the API? Does the concept of size introduced in the API impact (or need to impact) how a browser renders the winning ad?

A potential alternative would be a more generic concept of a "named creative variant" – that also can participate in a render URL macro substitution, as well as the K-anonymity checks.

Yes, the size returned from generateBid determines the size of the ad creative when it is loaded into a fenced frame from the ad creative's perspective, and the requestedSize passed into runAdAuction determines the size of the fenced frame from the embedder's perspective (unless overridden on the HTML element attributes). So the API does need to understand the width/height semantics. I thought I mentioned this but it looks like I forgot it when adapting the earlier proposal writeup. I'll fix it; thanks for noticing.

Are there any particular use cases for a "named creative variant" that you have in mind? We've previously talked about how fenced frames could support flexible sets of permissions (which would also need the API to have special understanding), and are thinking about how we might be able to handle things like native ads (which could pass an unstructured collection of information that the API doesn't need to understand, like you suggest).

Are there any particular use cases for a "named creative variant" that you have in mind?

Didn't have immediate use cases in mind when I wrote this originally; perhaps, one could think about styling variants – background/highlight colors, fonts and text size, etc., while advertising essentially the same exact good or service, with styling depending on the publisher page context.

The reason I brought this up is to test whether the API complexity around an explicit concept of sizes is worth it, or whether some more general concept would suffice.

unless overridden on the HTML element attributes
It seems, then, that the embedder already has the ability to control the rendering size via FF attributes – and requestedSize would simply be an additional mechanism that does the same, not net new functionality, correct?

size returned from generateBid determines the size of the ad creative when it is loaded into a fenced frame from the ad creative's perspective
Does that impact rendering by the browser in some way? If so, how?

Then in brief yes, it is necessary to have an explicit concept of sizes because it exists at the boundary between the embedder and the fenced frame content. For styling (this is what I meant by native ads), the fenced frame wouldn't need any understanding because the changes would be strictly inside the fenced frame content in JS, so the API could be more generic.

We are definitely still looking for ways to simplify the API while making it more flexible (in the long term). The main motivation for the k-anon check on sizes is to mitigate potential leaks from the network side channel in fenced frames, so if/when we can find a different solution there, we would likely be able to make this more generic/flexible (because there would be less concern about information flowing into the fenced frame).

It seems, then, that the embedder already has the ability to control the rendering size via FF attributes – and requestedSize would simply be an additional mechanism that does the same, not net new functionality, correct?

Correct, that's why it's forever-optional (not just opt-in for a transition period). But we figure that the publisher is probably telling the auction what size the ad slot is anyway, so they might as well use this field and avoid having to specify it again later in the HTML element attributes.

Does that impact rendering by the browser in some way? If so, how?

This is the browser's source of information for the size of the fenced frame's "inner frame" (i.e. the size of the content). In the old design, when you load a urn into a fenced frame, it freezes the size of the inner frame based on the size at the time of navigation (subject to an allow list), which causes all sorts of problems (privacy, but also performance because layout is asynchronous). In this new design, that frozen size comes synchronously from the urn/config instead.

It would be helpful to describe more explicitly how these sizes would be used.

Added some description of this immediately below, namely:

• They're used to prefetch k-anonymity checks
• When an ad with one of these sizes wins an auction, the size is substituted into URL macros
• When the ad is loaded into a fenced frame, the browser freezes the fenced frame's inner dimensions to this size

Can we clarify what filtering during the auction is being referred to here – and who (a browser, a buyer, or a seller) would be responsible for such filtering?

Below, it is mentioned that

optional requestedSize field recommends a frame size for the auction

and

Bidders inside the auction may pick a different size, but that resulting size will be scaled to fit inside the requested size.

This seems to imply that the browser would not be performing such filtering, and a seller and/or a buyer may choose – but do not have to – perform such filtering. Is that correct?

We haven't decided/specified what kind of filtering might happen yet. I meant that in the future, if there is demand for it, we could add the sizes to interest group filtering to help avoid unnecessary bidders. It's possible that you could fit that into the filtering framework already though; I'm not familiar with the details. I'll just delete this mention of filtering.

Back to the subject discussed on the Fledge call - https://github.com/WICG/turtledove/blob/main/meetings/2022-11-09-FLEDGE-call-minutes.md and in the github issue - #312 (comment):
to be able to implement carousel (or other type of animation in creative that present single product in two ways) we should define each product twice - which effectively - decrease this constraint to 10.
Could you consider two options:

• increase limit from 20 to 40 ?
• or limit 20 would only verify unique adComponent renderUrls (duplicated urls would be treated as single)

We'll discuss this and get back to you. From my perspective, the latter option sounds pretty unobjectionable, but I wasn't involved in picking the original max number of components so there might be something I'm missing.