Double-keyed caching: Browser cache partitioning
addyosmani.com
Double-keyed caching: Browser cache partitioning
1–10 of 29 posts
Re: Double-keyed caching: Browser cache partitioning
#2As 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.
Re: Double-keyed caching: Browser cache partitioning
#3As 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.
This also dramatically increases your fingerprintability, I think. Fingerprinters probably aren't using it yet though, because it's such a small target audience. But if it were to be implemented into a major browser, I'm sure they'd start using it.
Re: Double-keyed caching: Browser cache partitioning
#4The author recommends Domain Consolidation however this seems like some bad advice in certain cases due to the browsers max connection limit on domains. At least in http 1.0. or am I mistaken ?
Re: Double-keyed caching: Browser cache partitioning
#5This 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?
Re: Double-keyed caching: Browser cache partitioning
#6As 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.
This also dramatically increases your fingerprintability, I think. Fingerprinters probably aren't using it yet though, because it's such a small target audience. But if it were to be implemented into a major browser, I'm sure they'd start using it.
To elaborate, JS running on a page can probe your cache (via timing) to discern which URLs are already in it or not. If the cache is shared cross-origin, then it can be used to leak information cross-origin.
Re: Double-keyed caching: Browser cache partitioning
#7This 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?
The privacy implications are discussed in the article.
Re: Double-keyed caching: Browser cache partitioning
#8I’ve been beating this drum for many, many years now: https://csswizardry.com/2019/05/self-host-your-static-assets...
Re: Double-keyed caching: Browser cache partitioning
#9The author recommends Domain Consolidation however this seems like some bad advice in certain cases due to the browsers max connection limit on domains. At least in http 1.0. or am I mistaken ?
You are correct that this is an optimisation only available to H2+, but optimising to the H/1.x use-case is a use-case not worth optimising for—if one cared about web performance that much, they wouldn’t be running H1/.x in the first place.
Most connections on the web nowadays are over H2+: https://almanac.httparchive.org/en/2024/http#http-version-ad...
Re: Double-keyed caching: Browser cache partitioning
#10This 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?
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 functionality to be removed- if so what?