3 ms·

This is very much not my area of expertise, but there are a few things that I think could be challenging. Let's assume that a cached resource loads in ~0.1 seco

This is very much not my area of expertise, but there are a few things that I think could be challenging. Let's assume that a cached resource loads in ~0.1 seconds and an uncached one loads in ~1.0 second: * Any random delay of up to less than 0.9 seconds is completely pointless since we would know that any resource that loads in 0.5 seconds has to be cached - the 0.4 seconds spent waiting is useless. * A random delay of up to a second creates ambiguous cases: is 1.1 a cached + maximally delayed response or an uncached but only slightly delayed response? But, with a random delay, we're still going to have pretty different peaks in the expected latency graphs for cached and uncached resources - uncached ones would peak around 0.5 seconds and cached ones would peak around 1.5 seconds. * A random delay much more than a second would start causing the peaks on our expected latency graphs to be closer together - at a 10 second delay, we'll have a peak in the graph around 5 seconds for cached resources and 6 seconds for cached ones. I'm a bit fuzzy on how many resources we'd have to load to get a statistically significant finger print. I suspect its not all that many - but I could be wrong. However, we're also talking about a pretty significant delay by this point. We also have the issue of how to handle AJAX requests. You only get one shot to measure the initial load. But, after that you can make an AJAX request to re-load that same resource with caching disabled and measure that. I'm not a statistician, but, I suspect that that information will be pretty helpful in figuring out what was cached vs not cached. Of course, we could add in some random delays here too - but since we can measure this an unlimited number of times, I suspect this would be even easier to defeat. So, my suspicion is, that these type of random delays are possible to defeat if you have a better grasp of statistics than I do. But, we could also assume that that is not the case and that they can't be defeated - what does that get us? We've had to add all these random delays in to block the side channel which is going to hurt latency - the very thing we're trying to improve with caching. I also suspect there is a ton of complexity to consider if you want to avoid having all of the same random delays on repeated visits.

a1369209993 5y ago
Isn't the obvious solution here to just cache the delay? The browser presumably knows how long the original resource request took when site A made it, so it can just expose the same latency to site B and - since the cache by definition only hits if the request is identical - site B can't tell whether it's delayed by artificial cache latency or actual network latency. Chuck a symlink to the resource into each per-origin cache so non-initial requests still finish immediately, and possibly add a small chance of silently retrying the underlying request to see if it gets faster (with probability that can be computed entirely from site-B-observable load times).
- dagenix 5y ago
  Caching the delay defeats a big purpose of the cache in the first place - to reduce latency. But, also, the entity trying to fingerprint the request might also control the CDN - in which case, they can control the latency of non-cached requests. So, maybe in even minutes non-cached requests complete fast, but in odd minutes they are slow - in which case, a deviation from that behavior could be detected as a signal.
  - a1369209993 5y ago
    > a big purpose of the cache in the first place - to reduce latency. You can't reduce first-visit-to-site-B latency below what it would be if you hadn't visited site A and also not reduce first-visit-to-site-B latency below what it would be if you hadn't visited site A; no possible delay policy will help with that. > they can control the latency of non-cached requests. This is more of a problem, but it doesn't need latency as such - site B could compare request traffic to b.example versus cdn.example to see whether a request was skipped due to already being cached. (To be clear, I'm not sure you can actually do cross-origin caching securely for web traffic, for the above reason; I was addressing the narrow question of how to pick a delay - namely, don't delay cached and uncached responses by the same amount relative to their naive latency, because the whole point is that their naive latencies are different and we're trying to make that not true.)

a1369209993 5y ago

Isn't the obvious solution here to just cache the delay? The browser presumably knows how long the original resource request took when site A made it, so it can just expose the same latency to site B and - since the cache by definition only hits if the request is identical - site B can't tell whether it's delayed by artificial cache latency or actual network latency. Chuck a symlink to the resource into each per-origin cache so non-initial requests still finish immediately, and possibly add a small chance of silently retrying the underlying request to see if it gets faster (with probability that can be computed entirely from site-B-observable load times).

dagenix 5y ago
Caching the delay defeats a big purpose of the cache in the first place - to reduce latency. But, also, the entity trying to fingerprint the request might also control the CDN - in which case, they can control the latency of non-cached requests. So, maybe in even minutes non-cached requests complete fast, but in odd minutes they are slow - in which case, a deviation from that behavior could be detected as a signal.
- a1369209993 5y ago
  > a big purpose of the cache in the first place - to reduce latency. You can't reduce first-visit-to-site-B latency below what it would be if you hadn't visited site A and also not reduce first-visit-to-site-B latency below what it would be if you hadn't visited site A; no possible delay policy will help with that. > they can control the latency of non-cached requests. This is more of a problem, but it doesn't need latency as such - site B could compare request traffic to b.example versus cdn.example to see whether a request was skipped due to already being cached. (To be clear, I'm not sure you can actually do cross-origin caching securely for web traffic, for the above reason; I was addressing the narrow question of how to pick a delay - namely, don't delay cached and uncached responses by the same amount relative to their naive latency, because the whole point is that their naive latencies are different and we're trying to make that not true.)