Post

daniel r(ooooooh) in nyc 🇺🇸
@danielroe.dev

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.
Swizec Teller
@swizec.com

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

Ben Schwarz
@benschwarz.bsky.social

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

Thomas Steiner
@tomayac.com

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.

0 reposts4 likes

Ben Schwarz
@benschwarz.bsky.social

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 😂

Thomas Steiner
@tomayac.com

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.