Add optional slot-size parameters to trustedBiddingSignalsURL requests

[MattMenke2]

This is a slightly modified version of the proposal in issue #869.

[MattMenke2]

Note that this PR does not yet specify order in the multiple ad-slots case.

[MattMenke2]

We could also consider taking a list of options, instead of a mode, which is a bit more extensible. e.g.:

trustedBiddingSignalsExtraParameters: ["slot-size", "all-slots-requested-sizes"]

There's likely no benefit in combining those two, but it allows more easily adding other parameters, if we expect to do so in the future, rather than adding a new field for each option we may want to add.

[dmdabbs]

normalized width and height from the requestedSize of the top-level auctions AuctionConfig.

To what does normailzed refer?

Nits:

s/auction/auction's
s/allSlotsRequsetedSizes/allSlotsRequestedSizes

Params have been camel cased, so perhaps

&slotSize=<width>,<height>
&slotSizes=<width1>,<height1>,<width2>,<height2>,...

@JensenPaul provided this caveat in the #869 thread:

NOTE: specifying a mode of “thisSlot” or “allSlots” will cause the browser to include the slot size(s) in the trusted bidding signals request for this interest group, which may in turn be coalesced with requests for other interest groups that may not have specified a trustedBiddingSignalsSlotSizeMode.

Verifying that this proposes to alter the coalescing scope (emphasis mine)...

share a trustedBiddingSignalsURL and trustedBiddingSignalsSlotSizeMode

[MattMenke2]

normalized width and height from the requestedSize of the top-level auctions AuctionConfig.

To what does normailzed refer?

Sizes are strings with case suffixes, and parsing rules I haven't fully grokked yet. If this allows multiple variants of the same value (e.g., "100 PX", "100px", I don't think we want to preserve the exact details of how the string was formatted, to minimize side channels, and URL variation based on who created the AuctionConfig.

Nits:

s/auction/auction's s/allSlotsRequsetedSizes/allSlotsRequestedSizes

Both fixed.

Params have been camel cased, so perhaps

&slotSize=<width>,<height>
&slotSizes=<width1>,<height1>,<width2>,<height2>,...

Thanks for catching that - also a typo.

@JensenPaul provided this caveat in the #869 thread:

NOTE: specifying a mode of “thisSlot” or “allSlots” will cause the browser to include the slot size(s) in the trusted bidding signals request for this interest group, which may in turn be coalesced with requests for other interest groups that may not have specified a trustedBiddingSignalsSlotSizeMode.

Verifying that this proposes to alter the coalescing scope (emphasis mine)...

share a trustedBiddingSignalsURL and trustedBiddingSignalsSlotSizeMode

I'm concerned about ambiguities here - in the unlikely case one buyer uses single slots for one IG and all slots for others, it would potentially be a coin flip which request we merged with (and would also depend on which other IGs the user has been added to). I'm not really comfortable with that. Particularly if we add more things like this, it just seems like things can get worse and worse. I'd really rather not merge. The only argument I've seen for merging is for the 1-30 day ramp up period when a site starts adding these (if it uses update URLs, can update old IGs pretty quickly), and I think that case is niche enough to not be worth adding more ambiguity to auction behavior.

[dmdabbs]

I'm concerned about ambiguities here
Particularly if we add more things like this, it just seems like things can get worse and worse.

Yes. Not contesting, just verifying.

and I think that case is niche enough

Not following the case.

[MattMenke2]

and I think that case is niche enough

Not following the case.

The use case is if a buyer starts adding one of these params to its IGs (because it decided it wants to use the feature, either because it was just added, or if a buyer just decides it wants information it didn't need before), there's a ramp up period where some IGs have the new option and some don't, when we aren't merging the trusted signals requests, but doing so would probably be harmless to the buyer, and would improve performance. That seems the main case where merging them would be useful.

[dmdabbs]

Other size as string thing typos...

Each size has the format {width: widthVal, height: heightVal},
pixel units (e.g. 100 or '100px')
{width: '100sw', height: 50}

Thanks for the reminder re. normalized:

Sizes are strings with case suffixes, and parsing rules I haven't fully grokked yet. If this allows multiple variants of the same value (e.g., "100 PX", "100px", I don't think we want to preserve the exact details of how the string was formatted, to minimize side channels, and URL variation based on who created the AuctionConfig.

Quesitons, perhaps OT from the TBSU parameter, but adjacent...

• is leading/trailing whitespace removed from sizes (or sizegroup names)
• what happens when encountering a negative width/height
• what happens when encountering an unknown width/height suffix ('px,sw,sh')
• what happens when encountering an inappropriate width or height suffix ('sw,sh')

And specific to the TBSU parameter,

• pixels are the default (values without suffix are pixels). So will any values specifying px/PX be normalized (either internally [shaves storage bytes]) or in the TBSU param to remove the 'px'?

[MattMenke2]

So I'm looking at the regexp our size parser uses, and it looks pretty rigid: R"(^\s*((?:0|(?:[1-9][0-9]*))(?:.[0-9]+)?)(px|sw|sh)?\s*$)".

Looks like the only thing it allows are leading/trailing whitespace, and trailing zeroes. It's case sensitive, does not allow negatives (though does allow 0), allows no whitespace between units, no unrecognized units (so just px, sw, sh, and empty, which is the same as pixels), no leading zeroes / leading "0x", etc. So I think we'll basically just remove leading/trailing whitespace, and potentially trailing 0's and the decimal if there are only zeroes after it. We basically parse the information we can from the value, store that.

When we want a string, we have to serialize that back to a string. We could remember the original string and what we parse it to, but that seems not great in terms of IG size and extra information leakage.

I think if there's demand for it, we could at least remember the "px" vs empty, though that would require a database format update, and we'd have to force pre-existing IGs into one bucket or the other.

[dmdabbs]

Thanks!

does not allow negatives (though does allow 0)

What's the use case for a 0 anything banner dimension?

So I think we'll basically just remove ... and potentially trailing 0's and the decimal if there are only zeroes after it.

No legit/practical use for fractional/decimal pixel-specified banner sizes.

We basically parse the information we can from the value, store that.

So you store the extracted string, then.

No, no demand for anything more. Just wanting to understand how it is parsed / normailzed.

[MattMenke2]

does not allow negatives (though does allow 0)

What's the use case for a 0 anything banner dimension?

None that I'm aware of - I'm just describing what the existing parser does, at least according to my reading of it. Presumably at some point we'll require it to match a valid ad sizes, or at least silently throw away invalid sizes (for better forward compatibility, if new ad sizes are expected to occasionally be added).

[dmdabbs]

None that I'm aware of - I'm just describing what the existing parser does, at least according to my reading of it.

Appreciate your readout.

Presumably at some point we'll require it to match a valid ad sizes, or at least silently throw away invalid sizes (for better forward compatibility, if new ad sizes are expected to occasionally be added).

Right. In PA there's no notion of 'globally valid' ad sizes. Sure, IAB has standard banner sizes, but in the spec the IG owner determines their creative assets' sizes. And that's fine, since they could have agreements for non-standard sizes with pubs, or use them in O&O cases, &c.

Want to better understand why the browser should permit a top-level seller to embed a 0-anything or fractional dimension banner. That's OT to this new TBS mode param.

[MattMenke2]

I've now added a description of the two transformations normalized does.

Looking at the code, we have an IsValidAdSize() method that rejects size 0, but we don't actually seem to call it when parsing ad sizes, so I think 0 is actually not allowed, we're just not disallowing it the way we should be (I think we might currently kill a renderer process if we see it? That's not good - anyhow, I'll work on that).

[MattMenke2]

I've switched to using the component auction's sizes, to be a bit more consistent with the requestedSize that's passed to generateBid(). If we want to always use the top-level auction's size instead, we can change both together.

[dmdabbs]

The adSize section indicates sw/sh are integer not decimal-valued:

For example, the size {width: '100sw', height: 50} describes an ad that is the width of the screen and 50 pixels tall. The size {width: '100sw', height: '200sh'} describes an ad that is the width of the screen and has a 1:2 aspect ratio.

[MattMenke2]

I honestly have no clue what they are. Are they percents as decimals? Percents as numbers? Fenced frame spec doesn't mention them at all. I don't know where to find this information.

[MattMenke2]

So they're percents out of 100, and the 0.5 was wrong. Apparently that's how vw and vh work in CSS. Fixed.

[dmdabbs]

@JensenPaul can you shed any light on it?

[dmdabbs]

Are they percents as decimals? Percents as numbers?

Brought this to mind: They're both!.

[MattMenke2]

So I missed that in the original proposal, it was required that allSlotsRequestedSizes must include requestedSize. I guess we should add that requirement here, and require that if allSlotsRequestedSizes is set, requestedSize be set as well?

…

On Mon, Dec 4, 2023 at 2:02 PM David Dabbs ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In FLEDGE.md <#928 (comment)>: > @@ -597,7 +597,7 @@ Buyers may want to make on-device decisions that take into account real-time dat https://www.kv-server.example/getvalues?hostname=publisher.com&keys=key1,key2&interestGroupNames=name1,name2&experimentGroupId=12345&slot-size=100,200 -The base URL `https://www.kv-server.example/getvalues` <https://www.kv-server.example/getvalues> comes from the interest group's `trustedBiddingSignalsURL`, the hostname of the top-level webpage where the ad will appear `publisher.com` is provided by the browser, `experimentGroupId` comes from `perBuyerExperimentGroupIds` if provided, `keys` is a list of `trustedBiddingSignalsKeys` strings, and `interestGroupNames` is a list of the names of the interest groups that data is being fetched for. `trustedBiddingSignalsSlotSizeMode` is one of `none` (which is the default), `slot-size`, and `all-slots-requested-sizes`. In the second case, `&slotSize=<width>,<height>` is appended to the URL, where width and height are the normalized width and height from the `requestedSize` of the (component) auction's AuctionConfig. In the `all-slots-requested-sizes` case, `&slotSizes=<width1>,<height1>,<width2>,<height2>,...` is appended, where all sizes are taken from the (component) auction's `allSlotsRequestedSizes` value. If the corresponding value is not present in the auction, no value is appended. The requests may be coalesced (for efficiency) across any number of interest groups that share a `trustedBiddingSignalsURL` and `trustedBiddingSignalsSlotSizeMode` (which means they also share an owner). +The base URL `https://www.kv-server.example/getvalues` <https://www.kv-server.example/getvalues> comes from the interest group's `trustedBiddingSignalsURL`, the hostname of the top-level webpage where the ad will appear `publisher.com` is provided by the browser, `experimentGroupId` comes from `perBuyerExperimentGroupIds` if provided, `keys` is a list of `trustedBiddingSignalsKeys` strings, and `interestGroupNames` is a list of the names of the interest groups that data is being fetched for. `trustedBiddingSignalsSlotSizeMode` is one of `none` (which is the default), `slot-size`, and `all-slots-requested-sizes`. In the second case, `&slotSize=<width>,<height>` is appended to the URL, where width and height are the normalized width and height from the `requestedSize` of the (component) auction's AuctionConfig. "Normalized" means units are always appended, and trailing zeros are removed, so {width: "0.50sw", height: "10.0" becomes "0.5sw,10px". In the `all-slots-requested-sizes` case, `&slotSizes=<width1>,<height1>,<width2>,<height2>,...` is appended, where all sizes are taken from the (component) auction's `allSlotsRequestedSizes` value. If the corresponding value is not present in the auction, no value is appended. The requests may be coalesced (for efficiency) across any number of interest groups that share a `trustedBiddingSignalsURL` and `trustedBiddingSignalsSlotSizeMode` (which means they also share an owner). Are they percents as decimals? Percents as numbers? Brought this to mind: They're both! ***@***.***/video/7205011129590926634>. — Reply to this email directly, view it on GitHub <#928 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFAGH4NPA4JIRY7QMGQLF7LYHYM55AVCNFSM6AAAAAA7WPEKJKVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTONRTGE3TSOBWGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[dmdabbs]

Disconnect between the illustrative URL

&slot-size=100,200

and the paragraph

In the second case, &slotSize=<width>,<height> is appended to the URL,

[MattMenke2]

The first is a sample URL, rather than a template. The second is telling you the what the values mean. This is really the only place we explicitly mention that width is first (admittedly, the next line demonstrates it is), so I think this is probably the way to go?

[dmdabbs]

I was referring to the parameter name disconnect, which in either case is supposed to have fidelity to what Chrome will fetch, yes?

[MattMenke2]

I completely missed that. You're correct - and this is actually a bug in the current implementation. It should be using camelCase like everything else, but it is not. Thanks so much for catching this before we shipped anything! (Well, mostly - it's enabled on Canary with the wrong value). The all-slots-requested-sizes string also doesn't match the implementation. Anyhow, both issues should be fixed (Though still need to fix Chrome itself)

[dmdabbs]

You're welcome. I'll follow the bug you filed.

[michaelkleber]

I think all these different units are a little more distracting than helpful. Maybe just list two ad sizes here, one matching this requestedSize and one not? The available units can go down in the text where you talk about normalization.

[MattMenke2]

I'm not going to trim or rework the sizeGroups section in this CL, as I have no idea what a size group is, and that's really beyond the scope of this PR, so I am not going to trim down the adSizes block.

This PR is also not introducing the ad sizes units, and I'm not really very familiar with them, anyways, so I'm reluctant to dig into them here. I've just removed all the units. I'll leave mucking with them for another PR.

[dmdabbs]

auctionConfig.requestedSize --> &slotSize
auctionConfig.allSlotsRequestedSizes --> &allSlotsRequestedSizes

You opted not to use &slotSizes or perhaps &allSlotsSizes? Anyway, its shipping so the horse has left the proverbial barn.