This is something that is discussed at some length in the privacy section of the bidding and auction API explainer, but I found the conclusion there to be a bit weak, so I thought I would poke at this a little bit more.

My understanding of the shape of the API here is that the seller initiates an auction and the browser bundles up any interest groups that were selected by the seller into an encrypted blob that is then passed to the site. The expectation is that the site passes this bundle to the bidding and auction server, but I want to concentrate on the blob itself.

As noted, the size of this blob will leak information about the interest groups that were selected. The current strategy appears to be to limit the information release by padding to one of 7 (arbitrary? unspecified?) sizes. I don't believe that this is sufficient.

A seller has considerable flexibility in terms of selecting interest groups, both by specifying the set of buyers and by specifying per-buyer limits and interest group priorities. In effect, there is a rich query language for interest group selection. It's not entirely clear what the order of operations is, but my best interpretation is that this interest group selection executes before the encrypted bundle is assembled.

A seller can therefore query the cross-site database of interest groups and receive information back via the size of the blob. As it changes in size (including the case where no interest groups were registered), the seller learns cross-site information. Padding means that each query releases 3 bits of information. Two sites that coordinate efforts would therefore be able to re-identify a visitor from a planet-scale population in less than 11 invocations.

It is not clear to me that there are any effective means of rate limiting this sort of access to the API, to limit the rate at which this information might leak. There are plenty of good reasons that an auction might need to be abandoned under perfectly ordinary circumstances and less than 11 queries is a very small number to hide amongst usage of the API that is otherwise in the intended spirit of the API.

There is talk in #361 (comment) about the ways in which the number of interest groups might be reduced in number and size, but I don't see how that leads to a fix.