3 ms·

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

by 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.)

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.)