Such efforts are contra-indicated by privacy concerns. You'd need to have everybody agree what we're happy to just let everyone see, then that goes in the cache, and anybody who wishes we didn't know that they've just looked at, say, the Wikipedia page for HIV regrets everybody else's decision at their leisure.

Anything you decide needs to be private doesn't benefit from this cache. So, maybe we can cache the little Y-combinator logo, but not anything anybody wrote? The Youtube help pages, but not any videos? It just doesn't seem like there's any plausible way this isn't either horribly invasive or largely useless or both.

You are right, but there are other cases like say distribution of common JS libraries. The way it is working currently is via CDN, even then the client could fetch the same object from different sources. Instead if you could describe the object as some sort of signed E-Tag, then the client can just reuse previously downloaded/authenticated/decrypted copy. Of course your actual bank statement should not be distributed this way.

The privacy concerns aren't that easy to solve.

For example, let's say site G, well known for fingerprinting and tracking, wants to estimate how long since you last visited site W recently. W uses modern software engineering recommended practices: CI/CD with several deploys a day, heavily minimised EMCAScript, various icons too.

When you visit any page on G, G serves you a page that uses 37 scripts (called "signals") of particular exact, minified versions, which G happens to know M has served on any particular day. The scripts are loaded in such a way that they don't really do anything.

From that, G can estimate when you visited W, and on what day.

This works so well that G starts adding invisible iframes or AJAX calls to signed copies of entire popular pages from W, and through that, works out exactly what you've been reading. It takes a while because people read different things, but guess by guess, they build up a profile of your W reading habits over time, and the more accurate the profile becomes, the better they are able to estimate what pages to check next.

They do this even though you don't visit G all that often, because G's page does its measurements continuously while the page is loaded. You try turning off JavaScript, but G's A/B test-driven AI helpfully evolves a clever workaround with nested iframes and meta-refresh, so it doesn't make much difference.

Eventually this is done in G's ServiceWorker so it trickles along in the background, and G keep the bandwidth usage low enough that you don't notice. Battery consumption is hardly affected because they run their probes at the same time as the ubiquitous mobile-server-to-client-notification service wakes up the radio. Which 99% of users have running all the time.

A kind of "web crawling", if you will, but crawling the client's history, crawling shared, signed ETags just by trying them.

I'm unsure what you mean; intermediaries can absolutely cache responses regardless of whether they are retrieved with HTTP or HTTPS. One great example of this is Cloudflare itself, acting as a CDN for backing systems which serve content to Cloudflare protected with HTTPS.

If you are talking about a separate, non-intermediary cache service, this is neither part of HTTPS or HTTP. While there are certainly third party implementations that work this way, there isn't a generalized approach out there to solve this. Instead you have things like software caching services specific to a particular vendor, or things like Google AMP.

They’re talking about transparent caching HTTP proxies like Squid.

This is just IPFS, or BitTorrent with the serial numbers filed off.

I thought people wanting that used things such as HAProxy and https accelerators to deal with the encryption part before passing it onto caching and/or server apps.