Requesting early updates

[jeffkaufman]

In evaluating potential reliability risks from FLEDGE, one regression from today is in recovering from pushing bad data. If a buyer discovers that some clients have received bad data in response to their dailyUpdateUrl calls, the available options are not great. The buyer may be able to exclude the data from consideration via the trustedBiddingSignalsUrl call or ​​perBuyerSignals, but full recovery likely takes until the next dailyUpdateUrl (about half a day, on average).

One way to allow faster recovery would be to allow buyers to request calls to dailyUpdateUrl happen earlier than they would otherwise. For example, the response to trustedBiddingSignalsUrl could include an extra section like:

"requestEarlyUpdate": {
  "beginTimestamp": 1632000000,
  "endTimestamp": 1633000000
}

This would ask the browser to refresh any dailyUpdateUrl responses for this buyer last fetched between those two timestamps.

Buyers would, operationally, need to avoid a problem where a very large number of clients started calling dailyUpdateUrl all at once and their server received a large portion of a day's traffic in minutes. One way to solve this would be for the trusted bidding server to return a requestEarlyUpdate in response to a fraction of responses. The buyer could react in real time to the quantity of early update traffic they were receiving by telling the trusted bidding server to adjust the fraction of responses that were set to request an early update.

Browsers may be concerned with the possibility of buyers abusing this API to get faster updates in regular usage. One way to limit this would be for requesting an early update to count against a buyer's budget for future dailyUpdateUrl calls: you can request an early update, but only if you're willing to accept slightly less frequent dailyUpdateUrl calls for a while.