4 ms·

Why doesn't the browser just record the original request time for the resource and simulate the same download speed when a different domain requests it for the

Why doesn't the browser just record the original request time for the resource and simulate the same download speed when a different domain requests it for the first time? Maybe even randomize the delay some. Of course you get a false delay on first load but still saves network bandwidth while still preventing information leakage.

cesarb 7y ago
> but still saves network bandwidth while still preventing information leakage. If it saves network bandwidth, then you just have to measure the network bandwidth, like a speedtest page does. As Spectre and friends have shown, even the tiniest difference can be used for an information leak.
- icebraining 7y ago
  The speedtest pages work by measuring the time it takes to download a file. If the browser used a simulated time length, then the "bandwidth" will look the same.
  - AgentME 7y ago
    The attack idea is that a site could check if a file is cached by downloading a test file at the same time and seeing if the test file download speed is affected.
ken 7y ago
That's clever, but it still sounds like a way that information could be leaked. Download the target resource, and then download it again concurrently with a known unique resource, and see if the timing changes, for example. It's an arms race where the browser would ultimately have to simulate every consequence of actually downloading every resource over the slowest link in the network. You're making the problem (and its solution) more complex but not completely solving it.
- SigmundA 7y ago
  Yes I suppose adding a cache breaker query string will trigger a true network download that can be compared. Although if the network hasn't changed much the true and simulated should be very similar where would you really know if its a real or simulated request.
finchisko 7y ago
If you happen to download some resource on slow 3G, then all subsequent request will be slow?
- SigmundA 7y ago
  Only the first request from a different domain.
hyperpape 7y ago
In that case, the use of the shared cache doesn’t reduce latency, so you’re giving up over a big part, arguably the majority, of the benefit of caching. Where they come apart, I think it’s common to say latency is more important than bandwidth. It certainly is to me, though if you’re on a metered connection, you could certainly view things differently.
adrianmonk 7y ago
I think you'd also need to be careful about freshness of cached data. If you give stale data but delay it to give the illusion it was just loaded, an attacker might be able to infer it actually was from the cache after all by looking at the data and cross-checking that against what the current data looks like. Consider, as an example, an HTTP resource that contains a text string representing the current time and which is updated once a minute. Its cache lifetime is set to 1 minute. A page fetches it at 9:01:30AM and gets the string "9:01AM". This goes into the cache. At 9:02:15AM (45 seconds later), an attacker loads it, you give the cached data which is still the string "9:01AM". To cross-check the data, the attacker hits another server (say, its own proxy that it runs, which fetches the resource and forwards it on), so it can tell that the data it should have gotten is "9:02AM". In other words, if you give it stale data slowly, it might be able to detect the staleness instead of trying to detect the slow loading time. Perhaps you could fix this by validating the freshness of the cache, using ETags or something. You'd hit the server, validate what's in your cache is fresh, and then still delay it, thus giving a more complete illusion to the attacker. I'm not sure if HTTP allows a page to access the TTL of cached data, but if so, you might want to fake that too. If you give the real TTL numbers, then some of the time it's going to look like you just loaded it but it's about to expire.
pornel 7y ago
The article links to a reliable attack that doesn't need to test timing/bandwidth at all. It requests the resource from a page that has a very long URL, which causes the origin server to fail due to Referer header exceeding its header length limit. Cached = ok 200, Uncached = error 431.

cesarb 7y ago

> but still saves network bandwidth while still preventing information leakage. If it saves network bandwidth, then you just have to measure the network bandwidth, like a speedtest page does. As Spectre and friends have shown, even the tiniest difference can be used for an information leak.

icebraining 7y ago
The speedtest pages work by measuring the time it takes to download a file. If the browser used a simulated time length, then the "bandwidth" will look the same.
- AgentME 7y ago
  The attack idea is that a site could check if a file is cached by downloading a test file at the same time and seeing if the test file download speed is affected.

ken 7y ago

That's clever, but it still sounds like a way that information could be leaked. Download the target resource, and then download it again concurrently with a known unique resource, and see if the timing changes, for example. It's an arms race where the browser would ultimately have to simulate every consequence of actually downloading every resource over the slowest link in the network. You're making the problem (and its solution) more complex but not completely solving it.

SigmundA 7y ago
Yes I suppose adding a cache breaker query string will trigger a true network download that can be compared. Although if the network hasn't changed much the true and simulated should be very similar where would you really know if its a real or simulated request.

finchisko 7y ago

If you happen to download some resource on slow 3G, then all subsequent request will be slow?

SigmundA 7y ago
Only the first request from a different domain.

hyperpape 7y ago

In that case, the use of the shared cache doesn’t reduce latency, so you’re giving up over a big part, arguably the majority, of the benefit of caching. Where they come apart, I think it’s common to say latency is more important than bandwidth. It certainly is to me, though if you’re on a metered connection, you could certainly view things differently.

adrianmonk 7y ago

I think you'd also need to be careful about freshness of cached data. If you give stale data but delay it to give the illusion it was just loaded, an attacker might be able to infer it actually was from the cache after all by looking at the data and cross-checking that against what the current data looks like. Consider, as an example, an HTTP resource that contains a text string representing the current time and which is updated once a minute. Its cache lifetime is set to 1 minute. A page fetches it at 9:01:30AM and gets the string "9:01AM". This goes into the cache. At 9:02:15AM (45 seconds later), an attacker loads it, you give the cached data which is still the string "9:01AM". To cross-check the data, the attacker hits another server (say, its own proxy that it runs, which fetches the resource and forwards it on), so it can tell that the data it should have gotten is "9:02AM". In other words, if you give it stale data slowly, it might be able to detect the staleness instead of trying to detect the slow loading time. Perhaps you could fix this by validating the freshness of the cache, using ETags or something. You'd hit the server, validate what's in your cache is fresh, and then still delay it, thus giving a more complete illusion to the attacker. I'm not sure if HTTP allows a page to access the TTL of cached data, but if so, you might want to fake that too. If you give the real TTL numbers, then some of the time it's going to look like you just loaded it but it's about to expire.

pornel 7y ago

The article links to a reliable attack that doesn't need to test timing/bandwidth at all. It requests the resource from a page that has a very long URL, which causes the origin server to fail due to Referer header exceeding its header length limit. Cached = ok 200, Uncached = error 431.