News for hackers. Stuff that matters.

A comment on Shared Cache Is Going Away.

Re:Shared Cache Is Going Away by mikl on Sunday November 03, 2019 @11:23AM (#21434755)
Is it just me, or was shared caching not on its way out already? I mean, it was great when every website had jQuery on it, but with the proliferation of new JavaScript libraries, the chance of getting a shared cache hit must be getting smaller.

Besides, Webpack and similar bundlers with tree-shaking abilities makes it practical to just load a subset of a large library.

And last (but certainly not least) there is the security angle. Imagine if someone managed to sneak malicious code on to CDNJS or Bootstrap CDN, how many nasty things they might be able to get up to, even if everyone remembered to set crossorigin="anonymous" on their shared assets.

[ Parent | on HN ]
Re:Shared Cache Is Going Away by finchisko on Sunday November 03, 2019 @02:02PM (#21435831)
Not all shared resources are javascript. There are fonts and others too. Shared cache for fonts make sense to me even in 2019.
[ Parent | on HN ]
Re:Shared Cache Is Going Away by bepvte on Sunday November 03, 2019 @11:36AM (#21434852)
That is why SRI exists
[ Parent | on HN ]
Re:Shared Cache Is Going Away by SamHasler on Monday November 04, 2019 @08:44AM (#21441515)
It's not clear from the Chromium Design Document[1] whether resources loaded via Subresource Integrity (SRI) will have a shared cache or not. It's not explicitly mentioned, so it's probably best to assume it's not until someone has tested it.

[edit] The SRI spec github project has an issue for shared cache [2] that seems to be coming to the consensus that there will not be a shared cache for SRI:

> "it seems rather unlikely that we can ever consider a shared cache"

[1] https://docs.google.com/document/d/1XJMm89oyd4lJ-LDQuy0CudzB...

[2] https://github.com/w3c/webappsec-subresource-integrity/issue...

[ Parent | on HN ]