I’ve been beating this drum for many, many years now: https://csswizardry.com/2019/05/self-host-your-static-assets...
[deleted]
Double-keyed caching: Browser cache partitioning
11–20 of 29 posts
Re: Double-keyed caching: Browser cache partitioning
#12I’ve been beating this drum for many, many years now: https://csswizardry.com/2019/05/self-host-your-static-assets...
[deleted]
Re: Double-keyed caching: Browser cache partitioning
#13I’ve been beating this drum for many, many years now: https://csswizardry.com/2019/05/self-host-your-static-assets...
Regarding the resource hijacking (security vulnerability) risk, one need not just imagine it anymore. It actually happened, a few years after your blog post was written: https://news.ycombinator.com/item?id=40791829
Re: Double-keyed caching: Browser cache partitioning
#14Earlier quoted context omitted.
The privacy implications are discussed in the article.
You don't seem to have properly read the previous comment or the article. The question (not addressed in the article) is: is there in fact a gigantic, widespread problem of using cache-sniffing to fingerprint users? We have always known that this was possible, yet continued to include cross site caching anyway because of the enormous benefits. Presumably something fairly major has recently happened in order for this…
My guess, as someone who doesn’t know the answer but works closely in this field, is that the potential downside (i.e. privacy/security) was much greater than the actualised benefit (i.e. performance).
Safari (who make a big deal about being privacy-conscious) was the first to introduce cache partitioning, looking into it as far back as 2013[1]; Chrome followed in 2020 and Firefox in 2021[3]. One thing I know, anecdotally, to be a strong motivator among browser vendors is ‘X is doing it, why aren’t we?’
1. https://bugs.webkit.org/show_bug.cgi?id=110269
2. https://developer.chrome.com/blog/http-cache-partitioning
3. https://blog.mozilla.org/security/2021/01/26/supercookie-pro...
Re: Double-keyed caching: Browser cache partitioning
#15This seems to be quite a drastic change that could only have been warranted by a bigger problem than the one outlined in the article. Also strange the way than Osmani preemptively shuts down criticism of the change. What is the actual problem thats being solved here? Is cache-sniffing being actively used for fingerprinting or something? Whats going on here?
We should also be asking if the benefits of a non-partitioned cache are truly there in the first place. I think the main claim is that if (for example) the same JS library is on a CDN and used across multiple sites, your browser only has to cache it once. But how often does this really happen in practice?
Re: Double-keyed caching: Browser cache partitioning
#16This seems to be quite a drastic change that could only have been warranted by a bigger problem than the one outlined in the article. Also strange the way than Osmani preemptively shuts down criticism of the change. What is the actual problem thats being solved here? Is cache-sniffing being actively used for fingerprinting or something? Whats going on here?
We should also be asking if the benefits of a non-partitioned cache are truly there in the first place. I think the main claim is that if (for example) the same JS library is on a CDN and used across multiple sites, your browser only has to cache it once. But how often does this really happen in practice?
In the days of jQuery… all the time.
In the days of webpack, not so much.
Re: Double-keyed caching: Browser cache partitioning
#17As a user, you can use extension like LocalCDN. Instead of having your browser download common libraries and fonts, the extension would intercept the request and serve the local version. Even better in terms of privacy and security.
There is also one called Decentraleyes: https://decentraleyes.org/
Re: Double-keyed caching: Browser cache partitioning
#18As a user, you can use extension like LocalCDN. Instead of having your browser download common libraries and fonts, the extension would intercept the request and serve the local version. Even better in terms of privacy and security.
Why does this do anything? The attack described is a timing attack, so a local proxy doesn't really help.
Re: Double-keyed caching: Browser cache partitioning
#19A random fact from before the “before” in the article: the cache for all resource types used to be the same. We (ab)used this to do preloading before it was available in the web platform, e.g. download a JavaScript without executing it:
var js = new Image();
js.src = 'script.js';
js.onerror = function(){/* js done */};
Re: Double-keyed caching: Browser cache partitioning
#20This is annoying, can't we pretend to download the resources we have instead if just not doing it?