Hacker News Reader

Comment by judge2020 | Hacker News Reader

judge2020

I think the page that loads the resources itself would need the 'cache-sharing' header since other websites could still perform a timing attack if it loads a CDN asset that specifies 'cache-sharing true'. Even then, enabling cache sharing would still make you open to a timing attack and the effectiveness of a shared resource cache would dwindle as less and less sites share that cache.

View on HN

If Google Fonts serves Roboto with cache-sharing true that is unlikely to leak any data. Sure, you can detect that I at some point visited some site that uses Roboto, but that's vague enough to be useless.

There is some potential for leakage with uncommon assets. Maybe only a handful of websites use JQuery 1.2.65 or Helvetiroma Slab in font weight 100. It's a less severe vector than just testing if someforum.example/admin.css is cached, but still it's leaking data. The CDN could mitigate that by only sending a cache-sharable header on sufficiently popular assets, but depending on others going out of their way to preserve privacy is probably a bad idea.

If a website uses 10 common assets, that's often an uncommon combination. And if you have 100 websites on your "targets list" (let's say, fetish websites, or LGBT communities) then you could get a positive match on some of them.

The ten common assets have to be uniquely uncommon for this to be a risk. Tinymodeltrains.com might have a distinct combination of ten assets, but if my browser caches two of them from my visit to reddit, three from hackernews, two more from imgur, and the last three from pornhub, your tracking data will be meaningless.

Not entirely meaningless; it's kind of like a Bloom filter. False positives exist, but false negatives are unlikely. Combined with other data in the style of the Panopticlick, one can obtain a target set to which to apply closer scrutiny.

Then maybe have the browser enforce "common assets only" by tracking how many unique first party websites use a particular asset and only sharing the cache if the number of such sites is sufficiently high. Though I suppose that would reduce the effectiveness of the cache.

Many websites these days don't link 10 different files, they glob them at build time with gulp or whatever the latest hotness is, and serve one lib.js file instead.

The attack could still work in some cases, and is as described in the linked post.

Your webmail provider has a search box, and the content that is returned is styled with Roboto. If the search finds nothing, then Roboto isn't loaded. The attacker forces Rotobo out of the cache with a specially formatted fetch() request, then loads an iframe of the search. Then the attacker checks if Roboto is in the cache or not. This allows the attacker to essentially read your email inbox.

https://sirdarckcat.blogspot.com/2019/03/http-cache-cross-si...

I think it would be fine to let the CDN mark the common shared resource as "Caching: shared" as an opt-in, and also allow the including page to override with another header as an opt-out. If you are including shared cdn resources on a sensitive page, you are already doing it wrong. The CDN could already control its header to only send the opt-in for very commonly used resources in order to avoid fingerprinting based on less common ones.

This is a wonderful idea. You could also opt-in client-side with a shared attribute:

Reply on news.ycombinator.com