Improve Reporting Flow for B&A

[stguav]

In non-PAAPI ad serving, the outcome of the ad auction is entirely determined server-side, which allows a query event to be logged for every ad request with the corresponding auction winner, if there is one. Client PAAPI breaks this. By the end of serving the ad response, the winner of the server-side part of the auction is known; however, it is contingent on the outcome of the on-device auction, the so-called "one-bit leak" (see e.g. WICG/turtledove#211). This means that accurate reporting and logging requires an extra round-trip to the client. The extra round-trip can be lost, for example, if the user navigates away from the publisher page before the ad starts to render. More generally, this makes reporting fundamentally less reliable, experiment evaluation more difficult, and opens up the potential for new forms of IVT. Note that this potentially impacts even cases where the PAAPI auction loses to the server-side auction.

With the B&A serving flow, we have the potential to dramatically improve the reporting situation via two proposals:

1. We propose that when using B&A, the SFE makes the one-bit leak available to the SFE caller in plaintext. Exposing the one-bit leak in the SFE response, instead of requiring resolution in client-side JS code on the publisher page removes the negative reporting impact when PAAPI loses the auction. The one-bit leak is already available to JavaScript on the publisher page (potentially exposed to more parties), and can then be reported back to ad techs, so the incremental privacy risk seems small, and manageable.
2. While event-level reporting is available, we propose that auction result and winner reports be sent server-to-server from B&A, when the auction outcome is fully resolved. (If there are issues that obstruct fully resolving the auction server-side, we suggest prioritizing their resolution server-side within B&A.) Once the B&A auction is resolved, in addition to the one-bit leak, it should also be possible to make the auction result and winner report directly from the B&A servers. While making the one-bit leak available server-side primarily protects non-PAAPI winner reporting and logging, availability of the auction result and winner reports server-side protects PAAPI winner reporting. We expect that fenced frame reporting and beacons would continue to work as they currently do.

One concern might be that the server-side computation is more efficient and able to scale up exploitations of the one-bit leak for tracking or privacy invasive purposes; however, this seems mitigatable via a number of potential techniques, for example, rate-limiting with client-side generated nonces.

The proposal in (2) is a slightly breaking change from the existing behavior of PAAPI, where the URL set in sendReportTo() is "fetched when the frame displaying the ad begins navigating to the ad". To manage this discrepancy, an optional argument could be added to opt-in to early, more reliable reporting. There should be no actual reduction in utility for advertisers, since one could always trigger a "render" event beacon for measurement purposes.