Hacker News Reader

Comment by wongarsu | Hacker News Reader

> I'm sad about this change from a general web performance perspective and from the perspective of someone who really likes small independent sites, but I don't see a way to get the performance benefits without the [privacy] leaks

Maybe I'm missing something, but the obvious solution to me would be more cache-control headers.

The only notable case where shared cache is useful are resources on public CDNs hosting libraries and other common resources. These could just send a "cache-control: shared" header, or "cache-sharing: true" if adding new values to existing headers breaks too many existing implementations. This puts them in a shared cache, everything else gets a segmented cache.

View on HN

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.

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.

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.

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.

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:

Hypothetically, there's nothing to stop some useragents from "blessing" certain libraries as common enough to justify shipping them with the useragent and satisfying requests for them locally. That could leak details on useragent, but none that shouldn't be available from the http headers anyway.

But I suspect this will be unnecessary; even the bandwidth-constrained use case is getting to be more bandwidth every year.

You can try this out with an add-on like DecentralEyes.

https://addons.mozilla.org/en-US/firefox/addon/decentraleyes...

> Even the bandwidth-constrained use case is getting to be more bandwidth every year.

In my experience, websites are piling on bullshit faster than my mobile internet is getting faster.

This wouldn’t work for Safari, because Safari is trying to defend against data being transferred between even cooperating sites, as part of their anti-tracking work.

Reply on news.ycombinator.com