Unfortunately security and efficiency are at odds here.

We faced a similar dilemma in designing the caching for compiled Wasm modules in the V8 engine. In theory, it would be great to just have one cached copy of the compiled machine code of a wasm module from the wild web. But in addition to the information leak from cold/warm caches, there is the possibility that one site could exploit a bug in the engine to inject vulnerable code (or even potentially malicious miscompiled native code) into one or more other sites. Because of this, wasm module caching is tied to the HTTP cache in Chrome in the same way, so it suffers the double-key problem.

Can anyone find any data on how often cache hits happened for shared resources from CDNs anyway? How useful was this actually? I'm not confident it was a non-trivial portion of bytes fetched by a typical session. But maybe it was. Has anyone found a way to measure in any way?

My guess is the impact of cross site caching is negligible. We're losing nothing here.

1) Cache hit must be extremely low because of different versions/variants/CDN for each library. (Have you seen how many jquery there are?).

2) It's irrelevant outside of the few most popular libraries on the planet, maybe jquery/bootstrap/googlefonts.

3) Content is cached once on page load and the saving are happening over the next tens or hundreds pages you visit. That's where the gain of caching is (10x - 100x). Saving 1 load when changing site is negligible in the grand scheme of things.

For anyone asking what this means in numbers:

> The overall cache miss rate increases by about 3.6%, changes to the FCP (First Contentful Paint) are modest (~0.3%), and the overall fraction of bytes loaded from the network increases by around 4%. You can learn more about the impact on performance in the HTTP cache partitioning explainer. [0]

[0]: https://developers.google.com/web/updates/2020/10/http-cache...

Additional metrics: https://github.com/shivanigithub/http-cache-partitioning#imp...

> I have mixed feelings about these changes.

I feel for those on low bandwidth and low data limit connections. Website developers should focus on bloat and address that. That doesn’t seem to be happening on a larger scale though.

> It's excellent that browsers consider privacy, but it looks like anything can be misused for tracking purposes these days.

Of course. Every bit of information you provide to a site will be misused to track and profile you. That’s what the advertising fueled web has gotten us to (I don’t blame it alone for the problems).

I wasn’t aware that Safari had handled the cache privacy issue in 2013. It seems like it has always been way ahead on user privacy (thought it’s not perfect by any means). I’ve been a long time Firefox user who has always cleared the caches regularly, and I’m curious to know if any browser has consistently provided more privacy out-of-the-box than Safari.

I wonder how long it will take for browsers to go beyond the cache concept and implement an integrated package repository so I can upload my manifest + my 3kb app.js and tell the browser to download (and store) all the dependencies I need.

It will not only help with performance, but will also stop the absurd tooling madness that front-end has become.

So the natural progression here is that only big sites with their own CDN solution will be fast? And for most people and companies that will mean "rely on a large service to actual host your content for you", because they are not operating their own CDN. Because speed matters when it comes to search ranking.

So they are then beholden to major platforms such as Google to host sites for them from a global cache? Similar to what AMP does, but for all kinds of content?

Hmm.

Assuming all browsers are going to implement this partitioning, doesn’t it give web devs even more reason to use 3rd-party CDNs? You’re not paying for the traffic and you don’t have to worry about users’ privacy.

What is the most nightmare case of private information leaking here? I can't seem to come up with anything that horrible from my own imagining, especially not worth throwing away the advantage of cross domain resource caching.

The example that they give, that you're logged into Facebook, doesn't seem very useful other than maybe fingerprinting? But even then 90 some percent are going to be logged in, so the only real fingerprinting there is on the people who aren't.

So what we actually need is

- a decentralized way to store these libraries

- by a source with established trust (so it can't be misused for tracking)

JS/CSS library blockchain?

One of the benefits of using cdn resources is that it enables prototyping with, say, bootstrap so fast because you could essentially upload a single html file instead of a bunch of css, is,l and graphics. I mean, that will still be possible but there are more benefits to CDNs that just performance.

Even more food for thought - what if the cache is slower than the network? https://simonhearne.com/2020/network-faster-than-cache/

The negative effect is probably overblown; keep in mind that subsequent visits by the user to the same site can still use the cached version they loaded previously, and the odds of a cache hit in that case are relatively high.

I'm curious if this will result in any popular CDN folding. After a decent chunk of users update, they'll be hit with much more traffic than usual - and possibly more than they can afford in some cases.

Perhaps using content security policy headers for trusted CDNs could fix this?

No mixed feelings, this is unconditionally good. Who ever thought it was ok to force your users to download stuff from unrelated, commercial servers

ipfs and bittorrent v2 solves this problem by addressing content with hashes rather than URL.

At work we can no longer load stuff from CDNs anyway, because GDPR. For customer projects that is. I guess there would be the possibility to include it into some disclaimer but then we would need to check with the CDN about their data retention policy and check with the customer and that's just not worth it.