How would that help? You're incentivizing developers to mark everything "allowcache" (to make their pages faster), and it's the users who will suffer (via privacy attacks).
If your plan to fix this situation is "trust that developers are competent and benevolent", we can achieve the same result by not doing anything.
I want Roboto font to load instantly for my first time visitors and knowing Roboto is cached leaks basically nothing. On a personal level, I don't want any site to be able to figure out what media sites I am reading based on which images are cached in my browser.
"allowcache" would cause developers to do something stupid like put it on all images, but "multisite-shared" may cause developers to make reasonable choices.
A change that makes small sites a bit slower to load things like font becomes another brick in the wall of walled gardens.
The problem is that the security risks aren’t obvious and that feature would instantly lead to a ton of posts, StackOverflow answers, etc. saying you need to put it on everything for performance reasons (no doubt billed as a huge SEO advantage). Then we’d learn that, say, a Roboto load wasn’t so harmless when someone used it to detect fonts or Unicode subsets used by, say, Uighur or Rohinga sites out that the combination of scripts, font variants, etc. was more unique than expected.
The other thing to question is how much impact this actually has on small sites. CDN performance is variable enough that in the HTTP/2 era I’d be skeptical that most sites load times are significantly impacted by that rather than loading too much JavaScript or delaying rendering.
By default, all existing code would not have the allowcache property, so would load from an isolated cache. Those devs that explicitly care about speed for certain resources, where leaks are not a concern (e.g. loading a lib from a CDN) can set the allowcache property on those resources.
I think there are two categories of developers who would use that. One is smart, experienced people who have correctly evaluated both security and performance concerns and decided to turn this on for a specific narrow case where it's truly valuable to speed up first-time page loads.
The other is people who want things to go faster and flip a lot of switches that sound fast without really understanding what they do, and then not turning off the useless ones because they're not doing any real benchmarking or real-world performance profiling. This group will get little or no benefit but open up security holes.
Given the declining usefulness of shared caching (faster connections, cheaper storage, explosion of libraries and versions), I expect the second group to be one or two orders of magnitude larger than the first.
I agree with you, for now. But, I can imagine a future where library payloads will increase significantly. In those cases, shared caching will be pretty useful (I'm thinking along the lines of a ffmpeg WASM lib for web based video editing apps - sounds crazy, I know, but I think we're heading in that direction!). I could of course be totally wrong, and instead we just get fancier browser APIs with little need for WASM... I guess we wait and see!
If you're opening a video editing web app, I would expect a bit of loading time the first time trying the app.
WASM modules also execute as they load (unlike JavaScript, which only executes after being loaded), decreasing the value of relying on a cache in general.
> I can imagine a future where library payloads will increase significantly.
TBH I see the opposite; to use the focus of the article, jQuery was obviated by browser improvements, the pace of which is not really slowing down.
I'd like to know what you think "where leaks are not a concern" might mean. As a web developer, I have no idea how I'd be able to know that, even if I were perfectly benevolent and competent. Loading resources from a CDN is exactly the sort of thing that a malicious website can use for a timing attack.
This sounds to me no different than a developer wanting to opt-out of memory protection, on the basis that it will be a little faster -- and my program doesn't have any bugs or viruses!
But that's a separate issue, no? The leak issue is all about someone knowing whether you've accessed a resource previously or not (i.e. checking to see if the resource comes for cache or not).
For a lib hosted on a CDN, who cares?! However, if someone wants to track if you've been to myservice.com, they could try and load myservice.com/logo.png - if it's from the cache, then bingo, you've been there. That's a leak.
Maybe I've misunderstood; could you explain your timing attack mechanism in more detail please?
You don't need allowcache. You can do this already by serving script from domain under your control. The only potential problem is if attacker will also link same resource to your domain.
Something like:
<script src='jquery.js' allowcache></script>
That way we can specifically say which items we're willing to share with other sites and which ones we want an independent copy of.