It was even worse than that: https://sirdarckcat.blogspot.com/2019/03/http-cache-cross-si...

We could solve the privacy issue by implementing an installable plugin system into the browser. Let's call it NPAPI!

It seems like there could be some sort of cross origin cache header that could be set? That way by default you couldn't store in a global cache but server operators would be able to mark certain resources that could be.

Server operators would just set that header on everything. There's no downside for them. The privacy issue only impacts users and it would still exist even if only a subset of libraries were shared.

One proposed solution is checksums on CDN provided javascript:

https://w3c.github.io/webappsec-subresource-integrity/

Surprised the clients couldn’t just randomly add a small random delay on N percent of requests to nullify the side-channel info leakage.

It's my understanding that that type of countermeasure can be defeated with some statistical analysis.

Normally they could be, but it might actually work in this case. To do a statistical analysis, you need to be able to make many measurements. However, you only get one measurement per resource as a subsequent attempts will be cached regardless.

AFAIU you can invalidate the browser cache for a certain resource by hand:

> To delete the HTTP Cache, you just have to either issue a POST request to the resource, or use the fetch API with cache: "reload" in a way that returns an error on the server (eg, by setting an overlong HTTP referrer), which will lead to the browser not caching the response, and invalidating the previous cached response.

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

This is very much not my area of expertise, but there are a few things that I think could be challenging. Let's assume that a cached resource loads in ~0.1 seconds and an uncached one loads in ~1.0 second:

* Any random delay of up to less than 0.9 seconds is completely pointless since we would know that any resource that loads in 0.5 seconds has to be cached - the 0.4 seconds spent waiting is useless.

* A random delay of up to a second creates ambiguous cases: is 1.1 a cached + maximally delayed response or an uncached but only slightly delayed response? But, with a random delay, we're still going to have pretty different peaks in the expected latency graphs for cached and uncached resources - uncached ones would peak around 0.5 seconds and cached ones would peak around 1.5 seconds.

* A random delay much more than a second would start causing the peaks on our expected latency graphs to be closer together - at a 10 second delay, we'll have a peak in the graph around 5 seconds for cached resources and 6 seconds for cached ones. I'm a bit fuzzy on how many resources we'd have to load to get a statistically significant finger print. I suspect its not all that many - but I could be wrong. However, we're also talking about a pretty significant delay by this point.

We also have the issue of how to handle AJAX requests. You only get one shot to measure the initial load. But, after that you can make an AJAX request to re-load that same resource with caching disabled and measure that. I'm not a statistician, but, I suspect that that information will be pretty helpful in figuring out what was cached vs not cached. Of course, we could add in some random delays here too - but since we can measure this an unlimited number of times, I suspect this would be even easier to defeat.

So, my suspicion is, that these type of random delays are possible to defeat if you have a better grasp of statistics than I do.

But, we could also assume that that is not the case and that they can't be defeated - what does that get us? We've had to add all these random delays in to block the side channel which is going to hurt latency - the very thing we're trying to improve with caching. I also suspect there is a ton of complexity to consider if you want to avoid having all of the same random delays on repeated visits.

Isn't the obvious solution here to just cache the delay? The browser presumably knows how long the original resource request took when site A made it, so it can just expose the same latency to site B and - since the cache by definition only hits if the request is identical - site B can't tell whether it's delayed by artificial cache latency or actual network latency. Chuck a symlink to the resource into each per-origin cache so non-initial requests still finish immediately, and possibly add a small chance of silently retrying the underlying request to see if it gets faster (with probability that can be computed entirely from site-B-observable load times).

Caching the delay defeats a big purpose of the cache in the first place - to reduce latency. But, also, the entity trying to fingerprint the request might also control the CDN - in which case, they can control the latency of non-cached requests. So, maybe in even minutes non-cached requests complete fast, but in odd minutes they are slow - in which case, a deviation from that behavior could be detected as a signal.

> a big purpose of the cache in the first place - to reduce latency.

You can't reduce first-visit-to-site-B latency below what it would be if you hadn't visited site A and also not reduce first-visit-to-site-B latency below what it would be if you hadn't visited site A; no possible delay policy will help with that.

> they can control the latency of non-cached requests.

This is more of a problem, but it doesn't need latency as such - site B could compare request traffic to b.example versus cdn.example to see whether a request was skipped due to already being cached.

(To be clear, I'm not sure you can actually do cross-origin caching securely for web traffic, for the above reason; I was addressing the narrow question of how to pick a delay - namely, don't delay cached and uncached responses by the same amount relative to their naive latency, because the whole point is that their naive latencies are different and we're trying to make that not true.)

You should be able to do something like this:

- if the resource isn't in cache, download it and note the time it took.

- if the current site has requested the resource before, just return it instantly.

- otherwise, wait the exact same time it took originally.

With this the first request a site makes for a resource will always take the same time and you have no way of knowing if that was the first time it was downloaded or if it's served from cache. It's obviously not quite that simple, you'll need to factor in which connection is in use etc, but it should be possible to keep cross site caching.

Weren't the shared libraries used on countless sites though? How would this work?

Yes but each site uses a lot of libraries too. The set of libraries and specific versions of those libraries used by a site is a pretty good fingerprint.

Still doesn't make sense - there is only a single set of libraries - the ones cached by a user's browser, and since each library in that set is used by thousands of sites, there's no way to know which site it was cached for. For each version, there are certainly thousands of sites using it. Since I'm still not getting it, perhaps you could explain how a particular set of libraries is fingerprinted?

The New York Times uses libraries (versions) A,B,C, and D. Wikileaks uses A,B,D and F. I see that you have A,B,D and F cached - that allows me to rule out the NYT and predict with some degree of confidence that you visited Wikileaks.

You can make up theoretical models for how many popular libraries there are, or how many sites, and say this should or shouldn't be possible. I haven't seen any such models, but advertisers were definitely using this technique in the wild so the models that say it's impossible are all wrong.

Adding noise to a small sample of requests doesn't buy you that much entropy - the signal is a little noisy anyway.

This would work if you only visited like 5 sites. If you visit thousands, and more like tens of thousands when you consider 3rd party embedded content, you can't figure out which sites a user visits, but rather only which ones they don't.

It worked pretty effectively.

Think about the 10,000s of JavaScript libraries out there, and the 100s of versions of each.

number of libraries * number of versions ~= bits of information to classify you

A good intuition is that although there's low certainty which site you have visited, there's high certainty which sites you HAVE NOT visited

I think is easier to see how you can fingerprint someone based on the set of sites they HAVE NOT visited

Edit: I'm not so sure anymore, I think that requires to test looots of libraries, it's not practical unless you are a really nasty ad company that tests hundreds of libraries in the background really sucking up your bandwidth

I got a better idea

Imagine ad companies choose libraries that are roughly used by 50% of users, if they test you with 10 of those, they learn ~10bits of entropy to classify you, i.e. which of the 1024 classifications you belong

Because you'd make your own library used exclusively for tracking, or check to see if another site specific set of resources had been loaded.

How is that any privacy hole at all?

Millions of websites use vue (as an example) from the same CDN. There's no way to know which site it was cached from.

What a terrible thing they've done, making the internet slower for everyone on earth for no good reason.

Its pretty bold of you to assume that you know more about this problem than every browser developer.

Websites don't just "use Vue". They use some particular version of Vue along with particular versions of other libraries. My understanding is that once you put all of that together, this can create some significant privacy leaks.

By "they" do you mean advertisers? If so, I agree