Post

The amount of pain that this would cause a regulated software product would be horrifically large without an ability to opt out entirely. It’s a great idea, but hashes aren’t sufficient anymore for where regulations are trending Now, combine this with attestation and you have me very interested :)

this is opt in only

but i would love to know more about the issue with regulated sites… is it related to privacy?

Saw this and thought: why just commonJs ???

@tomayac.com how does this intersect with chromestatus.com/feature/5202...?

It is opt-in/explicit and is a hash-indexed cache independent of where it was served from (you can serve react core from your origin but benefit if someone already shipped it and still trust the payload). Also has different security and pervasiveness considerations.

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

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.

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.

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.

Yes, until ~7 years ago caches were *not* domain sharded for privacy. This used to work very well bsky.app/profile/swiz...

Throwback 2024: www.securityweek.com/polyfill-sup...

oh gosh I guess this counts as many years ago now huh

And that time Doug Crockford used this to make every website that used the JSON reference implementation alert("This website is vulnerable to Doug Crockford");

I recall seeing several proposals about popular library caches in the past decade. The general consensus was that it wasn’t worth it, and people didn’t want “blessed” libraries to gain an advantage that could hinder web progress. Is this proposal different in some way?

It's different in that it's hash-based, so we don't need to agree on the same CDNs (as when before the caches were isolated by origin). This means the cache hit rates would improve, as we work directly with fullstack frameworks like Nuxt, so they can consider COS at build time.

> of common js Just use esm bro (Har har)

Super interesting! Wondering if this could/should live on the browser layer instead of an API layer? E.g. could a browser do the heavy lifting automatically? Like, cached/shared network responses. Not sure how it would decide which files to cache though.

one part that requires bundler integration is that we have to ensure that the chunks are as byte-for-byte identical as possible. e.g. treeshaking, mangled export names, sourcemap comments, etc., need to drop out but then it's over to the browser when we expose the chunks as 'cacheable'

True! In my head it was as simple as "vue.js version x.y.z always ships as the same js file, with the same cryptographic hash, so it can be reused safely" but it's not that simple. And in any case a website has to dictate which files it actually needs. So maybe it's the right layer haha. Will try!

Wonder how this will work with tree-shaking, though I imagine it'll be most useful for larger things like WASM binaries etc.

By working with fullstack frameworks like Nuxt, we can make sure they output COS-friendly chunks that are the same for all Nuxt users on the same version. This even can mean bundling together different unrelated vendor libraries that just happen to be all used by the framework.

What about compiled frameworks like Svelte?

I'm working with @tomayac.com to build bundler integration for this (currently a nuxt module + a vite plugin) I'd love to know: 1️⃣ if this sounds like a good idea you'd use 2️⃣ if you wanted to test it out and see if it might make a difference for you ... happy to help if you have questions! 🙏

with so many supply chain issues lately, I would be very concerned about security with something like this. i love the idea for sure, but I personally lean toward security over convenience

I think the fact that resources are identified with cryptographic hashes is meant to prevent that kind of thing

Suspect ad networks etc will use it as a cross site fingerprinting and tracking storage Know the spec mentions this but it’s mitigation involves browsers sharing what’s in the cache to a central resource

I kinda feel like attack surface for cache poisoning would probably be high no?

i think the hash based addressing is meant to prevent that but you mean someone might find collisions?