Side channels for measureConversion operation #153
Comments
|
It seems like it would be very difficult to get the duration of the timer on the second process right; maybe it could be set in rough proportion to the number of records and/or capabilities of the host, but seems like likely to serve most users poorly. Did folks consider tactics like adding a random delays to the processing or, if there's concern about compute pressure monitoring, randomly choosing some number of records to reprocess and ignore those results? |
|
Discussed briefly on 2025-05-13: No real conclusion from that discussion. (My own sense is that we'll probably need to see a proposal before we can be confident that what we've got makes sense. It might even need to be implemented.) |
I read this to mean that when the timer runs out prior to the first thread finishing its work, the measureConversion() operation essentially fails and a null report is generated. If that's correct, it means browsers with the fullest impression stores and highest likelihood of recording a conversion are also going to be most likely to time out and report nothing. Clearly that would discourage adoption, so if we push forward with this approach we'll want to set the timer value as high as we can stand to make it. |
I think we're all aligned that we want to minimize loss with respect to side channel mitigations. It should be straightforward to track this in aggregate and ensure that the timer is set to have low loss.
|
|
Action on @apasel422: check on ARA latency figures and propose a cutoff for the timer. |
martinthomson
added
editor-ready
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.
The text was updated successfully, but these errors were encountered: