Post

wouldn't it be nice if sites could share a cache of common js? ... stuff like react, or vue or svelte? 👉 there's an early stage proposal for cross-origin storage which enables exactly this. there are challenges but I think it's very interesting indeed

github.comGitHub - WICG/cross-origin-storage: Explainer for the Cross-Origin Storage (COS) APIExplainer for the Cross-Origin Storage (COS) API. Contribute to WICG/cross-origin-storage development by creating an account on GitHub.

We used to have this many years ago by default. It was common to load jQuery et al from a public CDN so most people wouldn't have to download it again just for your site. Then marketers started using it to fingerprint. And hackers used it to poison cross-origin JS. The feature got removed sigh

2 reposts37 likes

It’s still a thing, Cloudflare has the big public CDN that does this now, but it was a product of its time. Internet Explorer had a limit of requests in-flight per server, so the extra DNS lookup cost was worth it. When that went away and we got HTTP/2, it mostly nullified the speed benefit

Right, but if you loaded the exact same jQuery from a different CDN, there was no cache hit. COS is hash-based, so now you can self host jQuery from swizecs-random-server dot com and still get a cache hit. The Public Hash List (github.com/WICG/cross-o...) proposal aims to mitigate the attacks.

github.comPublic Hash List as a way to solve the availability gating challenge · Issue #64 · WICG/cross-origin-storageThe explainer suggests vendors apply availability gating to decide whether a resource can be shared via the COS cache. The repo tomayac/public-hash-list contains some early explorations in the dire...

When we split the cache many years ago we anticipated a need for content-addressable storage (CAS) to improve caching. IIRC we envisioned enforcing k-anonymity locally, but big resource lists certainly help bootstrap. We also assumed it would just extend SRI, and just work for any SRI'd resource.

The Public Hash List can be augmented by local k-anonymity, right. But having a common baseline browsers (hopefully) agree on seems to make a lot of sense. The problem with "any SRI'ed resource" is that it includes supercookies a friendly neighborhood tracker would mint for you—so it can't be any.

Yeah, I get the lists as a k-anonymity seeding baseline. But the whole point of k-anonymity thresholds is to prevent super cookies. That's why I don't see why you wouldn't just extend SRI, when you've already got a good way to ensure strong k-anonymity.

These are the two big questions that jump out at me: 1. Why a separate API? Just extend SRI, to allow for the broadest and simplest use. 2. Why just published lists? If the browser sees a hash advertised in any form past a k-anonymity threshold then just use the CAS cache implicitly.

Due to the way caches are domain sharded for privacy, it doesn’t really work that well. Caches aren’t as effective as people had hoped. That, and a third party takeover of a CDN is too bigger security risk for most websites

Being hash-based helps us there. You can be sure about the content as long as the hash matches. A resource with hash abc123 put in the COS cache can be trusted, even if it came from sketchy-server dot com. The hash is checked before writing to COS.

Just peeped JS API in the readme and it reminded me of the Dropbox dropship hack where you could spoof file hash IDs to the API and get Dropbox to sync files that other users had in the cloud It immediately got abused as a way to distribute movies 😂

Yes, totally, SRI is a great assurance. It would be fantastic, once this rolls out, to get a filter for "built with resources on the Public Hash List" to see potential RUM impact.

This attack would not be possible with COS because it's hash-based. Say you expect jQuery 1.2.3 with hash def456 and good-become-evil dot com /jquery1_2_3.js suddenly serves a modified resource, then said resource would not be allowed in the COS cache for the hash mismatch.