Additional bids and fetch

[martinthomson]

Additional bids are not provided through the auction config passed to runAdAuction(), but rather through the response headers of a Fetch request, as described below in section 6.3 HTTP Response Headers. However, the auction config still has an additionalBids field, which is a Promise with no value, used only to signal to the auction that the additional bids have arrived and are ready to be accepted in the auction. For each additional bid, its owner must be included in interestGroupBuyers for that additional bid to participate in the auction.

I'm struggling to understand this piece in Section 6. The first sentence contradicts everything that precedes it, but I'm going to assume that is just a drafting error and the intent is to say that you can provide a promise in place of the structure as an alternative.

The promise here doesn't resolve to anything related to the structure that the API needs. Instead, it refers to something (the fetch) that might use some non-obvious channel to provide information for the auction. That seems problematic. If an implementation has no means of connecting a promise to the underlying fetch machinery that might contribute to the resolution of that fetch, this will be very difficult to implement. For instance, if there are reasons specific to an implementation (or a site) where the fetch promise is chained or wrapped, the promise that script receives might not be easily traced to the underlying fetch.

I can see why you might want to perform fetches for this in parallel to initiating the auction, so a promise makes some sense. However, this system precludes having any sort of hybrid system, where some additional bids are present and others need to be fetched. If the promise resolved to the described structure, then it would be possible to write code that assembles a set of additional bids from disparate sources.

The text seems to imply that there is some desire to authenticate this information, which is hinted at as the reason for tying to a fetch. The reasons for that are not articulated, nor can I guess what they might be. Why would the browser need to be assured that the bids are genuine in this way? I might infer that this is because somehow the browser is later generating signals that might need to be trusted, like the report it makes about what ad was placed¹.

Footnotes

1. If that is the case, then we might want to talk more generally about how trust is managed in this context, because this idea that script is untrustworthy relative to what comes over HTTP is not helping. The proliferation of HTTP-level signals due to this mistrust is damaging on multiple levels. ↩