Discussion topic here is what the nature of the leakage we are willing to tolerate for measureConversion(). Ideally, this is an operation that runs in constant time with respect to information that the site doesn't have. However, the main thing that the site doesn't have is the number of impressions that are searched. That's a fundamental problem here.

The best idea we presently have is to run two parallel processes. The first does the complex attribution logic that searches impressions and the real work of the API. The second runs a timer for a fixed amount of time, plus maybe some randomness. The first thread does not report its results; it only drops the results in a pre-arranged spot. When the timer pops for the second thread, it takes whatever value exists (which might be nothing if the first isn't finished), packages that up, and resolves the promise.

This isn't ideal, because it means that there will always be some amount of delay. Tuning the timer could even be difficult if we need to account for different performance profiles and loading. However, it means that we open up more options for what the attribution logic can do. We don't need to focus on being purely constant time in the sense that we would for cryptographic operations. At least not entirely: there will still be some leakage through cache timing and all of the Spectre and Meltdown style of attacks, but we can require that the processing be done out-of-process to help mitigate that. At a minimum, this would allow us to attain the same sorts of isolation protections that sites get from each other.

Alternative ideas are very much welcome here. The idea above is not ideal, because it will fail in some circumstances in ways that are inscrutable and it leads to delays that will be awkward to handle in some cases. This is not a topic that we have a clear answer on so far and improvements here might help make other parts of the work more robust, flexible, or performant.