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 m

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.