5 ms·
This 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
by fergie 2y ago
This 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?
- kibwen 2y agoThe privacy implications are discussed in the article.
- fergie 2y agoYou 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?
- csswizardry 2y agoMy 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 https://bugs.webkit.org/show_bug.cgi?id=110269 2. https://developer.chrome.com/blog/http-cache-partitioning https://developer.chrome.com/blog/http-cache-partitioning 3. https://blog.mozilla.org/security/2021/01/26/supercookie-protections/ https://blog.mozilla.org/security/2021/01/26/supercookie-pro...
- deleted 2y ago[deleted]
- Retr0id 2y agoWe 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?
- sroussey 2y agoIn the days of jQuery… all the time. In the days of webpack, not so much.
- shanemhansen 2y agoWell I know it's not directly the answer to your question, but the article mentions that in practice a partitioned cache increases bandwidth by 4%. Which at the scale of billions of web browsers is actually pretty bad.
- simonw 2y agoThe privacy problems were really bad. Want to know if your user has previously visited a specific website? Time how long it takes to load their CSS file, if it's instant then you know where they have been. You can tell if they have an account on that site by timing the load of an asset that's usually only shown to logged-in users. All of the browser manufacturers decided to make this change (most of them over 5 years ago now) for privacy reasons, even though it made their products worse in that they would be slower for their users.
- olliej 2y agoThe privacy problems were catastrophic - the Google CDN fed directly into Google’s pervasive tracking infrastructure. Most other CDNs similarly support tracking services. As the article says the actual cost of partitioning is negligible, the cost of not partitioning is that nothing can prevent cross site tracking and invasion of privacy. VPNs and extensions don’t work because the browser is ensuring your identity is constant. That’s why the large ad networks funded free/cheap CDNs.