Protect measureConversion algorithm from timing-based side channels

[apasel422]

Unfortunately, the WebIDL spec doesn't appear to contain an equivalent to
https://github.com/domenic/promises-unwrapping/blob/master/docs/writing-specifications-with-promises.md#aggregating-promises.

Fixes #153

---

Preview | Diff

[apasel422]

Thinking about this further, I'm not sure that the current PR is correct with respect to atomicity: Presumably we want to avoid committing any changes to persistent storage if the timeout is reached, which will involve restructuring the algorithms to avoid iterative writes.

Thoughts, @csharrison and @martinthomson?

[csharrison]

Good point. Even if we structure the storage to only do a single write, we need to be careful since that write could leak information, and e.g. we need a way method of canceling it / rolling back if the timeout occurs during the write. Alternatively, we could try to ensure the write time is always fast regardless of existing db contents by having some staging buffer table that has no indices, etc, which we process async. Then maybe we'd be OK hoisting the write out of the timeout-scoped block.

[martinthomson]

Hmm, if we're going to do that, we could split the attribution logic into two parts. The first will select candidate impressions and write to persistent storage (which I assume is just the various privacy budget store buckets that are touched). I think that the privacy budget store update always happens; it can't be cancelled. Then there will be a process of generating an answer, which could be cancelled.

It's possible that we only need to identify candidate epochs in that first pass, which would be fast and maybe even constant time. Not perfectly, but close. An impression store can't be split by epoch, because that's a conversion-site thing. It could have a bitmap for where impressions are by time, which would be a constant-time scan. That would result in some imprecision if you wanted true constant time: say you had a resolution of 10 minutes and aligned epochs on that boundary, you would have 1k bits per epoch per impression site of overhead.