Hacker News Reader

Comment by gostsamo | Hacker News Reader

A question: instead of redownloading the same resources again and again, can we achieve privacy by adding delay between requesting a resource and providing it? It could be the same amount of time it took downloading it the first time or some randomized value. It won't speed up pages, but at least will save from bandwidth and data caps.

View on HN

You don't need a timing attack as you could e.g. put a unique identifier in the resourcce you're delivering via the CDN. When the browser delivers the resource from its cache for another domain you could simply extract the identifier from it again to achieve cross-site tracking.

This is actually valid. Without third party to ensure the neutrality of the resource, this would be a unregulated cookie.

A better trap would be if the browser downloads the resource on the second request as well and compares the hashes. If they differ, the resource is considered uncachable.

I've read your comment 3 times, and I'm still not exactly sure what you are suggesting, or what the purported benefit is? (it's probably my poor interpretation, but I'd appreciate if you wouldn't mind expanding :)

He wrote that: save bandwith and data caps.

He would lose performance but win more privacy.

I understand the purpose of caching well enough; what I didn't understand was the proposal was to delay returning data from the cache.

This is based on trying to prevent profiling based on which fonts or versions of things are precached by behaving as if they are not cached, when in reality serving a local file with a simulated delay.

Site A can't see the cached resources of site B, because it would show that the user has visited site B if the resource is provided too fast. However, if the resource is provided with some delay, then site A assumes that site B hasn't been visited.

The current solution is to download the same thing twice. It is wasteful and I offer downloading it only once, but if site A asks for a resource for site B, the resource should not be returned immediately, but after a few ms so that site A gets the wrong conclusion.

It should work if site A can observe only the result of the request but can't check if a request happened or not.

Ah, right, I understand your point now. When sites determine if something is cached or not, are they doing it purely based on the time taken to load it?

Yes, as far as I've seen the issue explained. I'm not sure though so I'm asking if someone knows for a side-channel that would invalidate my solution.

This happens somewhat by ensuring that timing APIs in Javascript don't have very high accuracy. But these attacks have gotten more sophisticated over time, and any random noise can be filtered out.

I thought that the timing is for attacking the cpu cache, not the web one. A request might take 100ms so such inaccuracy will be regressing lots of functionality.

My idea is for such delays to be introduced transparently in the caching service of the browser, not the js engine.

Reply on news.ycombinator.com