4 ms·
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?
by gostsamo 6y ago
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.
- GordonS 6y agoI'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 :)
- wwosik 6y agoHe wrote that: save bandwith and data caps. He would lose performance but win more privacy.
- GordonS 6y agoI understand the purpose of caching well enough; what I didn't understand was the proposal was to delay returning data from the cache.
- mjevans 6y agoThis 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.
- gostsamo 6y agoSite 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.
- GordonS 6y agoAh, 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?
- gostsamo 6y agoYes, 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.
- captn3m0 6y agoThis 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.
- gostsamo 6y agoI 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.
- deleted 6y ago[deleted]
- ThePhysicist 6y agoYou 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.
- gostsamo 6y agoThis 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.