5 ms·

Per-site caching negates the principal selling point of centrally-hosted JS and resources, including fonts. The convenience remains, but all speed-related perks

by abcd_f 6y ago

Per-site caching negates the principal selling point of centrally-hosted JS and resources, including fonts. The convenience remains, but all speed-related perks (due to the resources being reused from earlier visits to unrelated sites) are no more... which is actually great, because it reduces the value that unscrupulous free CDN providers can derive from their "properties". It also means that I can remove fonts.google.com from the uBlock blacklist. Yay.

kristofferR 6y ago
LocalCDN is an extension I would recommend, both for privacy and performance reasons. https://www.localcdn.org/ https://www.localcdn.org/
- milofeynman 6y ago
  Decentraleyes is what I use. I assume they're similar https://addons.mozilla.org/en-US/firefox/addon/decentraleyes/ https://addons.mozilla.org/en-US/firefox/addon/decentraleyes...
  - kristofferR 6y ago
    LocalCDN is an updated fork of Decentraleyes. Decentraleyes hasn't been updated in ages, has few assets and its assets are massively out of date. https://git.synz.io/Synzvato/decentraleyes/-/tree/master/resources https://git.synz.io/Synzvato/decentraleyes/-/tree/master/res... vs https://codeberg.org/nobody/LocalCDN/src/branch/main/resources https://codeberg.org/nobody/LocalCDN/src/branch/main/resourc...
    - takeda 6y ago
      My Decentraleyes was updated in November 5th, that's not that long ago. LocalCDN extension has also a comment that Mozilla doesn't regularly monitor it for security.
      - Forbo 6y ago
        LocalCDN is much, much more actively developed than Decentraleyes. https://codeberg.org/nobody/LocalCDN/commits/branch/main https://codeberg.org/nobody/LocalCDN/commits/branch/main vs https://git.synz.io/Synzvato/decentraleyes/-/commits/v2.0.15 https://git.synz.io/Synzvato/decentraleyes/-/commits/v2.0.15 I'd imagine if LocalCDN got more popular than Decentraleyes, it would probably get Mozilla's seal of approval as a "recommended" extension. Then again I'm not entirely sure what their approval process for that looks like. Currently Decentraleyes has about 100x the userbase.
  - deleted 6y ago
    [deleted]
- nunez 6y ago
  Wow. This is really neat. I’m going to give this a shot!
PaulHoule 6y ago
That idea of having JS files hosted elsewhere always struck me as a Girardian scam (e.g. "everybody else does it") and always getting voted down when I showed people the reality factor. Nobody seemed to think it was hard to host a file before this came along, just as nobody thought it was hard to have a blog before Medium. Of course this creates the apocalyptic possibility that one of these servers could get hacked (later addressed with some signing) but it's also not easy to say you're really improving the performance of something if there is any possibility you'll need to do an additional DNS lookup -- one of the greatest "long tails" in performance. You might improve median performance, but people don't 'experience' median performance in most cases (it goes by too fast for them to actually experience it), they 'experience' the 5% of requests that are the 95% worst, and if they make 100 requests to do a task, 5 of them will go bad. People are miseducated to think caching is always a slam dunk and sometimes it is but often it is more nuanced, something you see in CPU design where you might "build the best system you can that doesn't cache" (and doesn't have the complexity, power and transistor count from the cache -- like Atmel AVR8) to quite a bit of tradeoff when it comes to 'computing power' vs 'electrical power' and also multiple cores that see a consistent or not view of memory.
- sanxiyn 6y ago
  It's not about being hard, it's about being convenient. Convenience is important. Even trivial convenience.
- mdavidn 6y ago
  Browsers can check "subresource integrity" to guard against hacks of third-party services. https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
  - nunez 6y ago
    Yeah but you, the developer, need to provide the hash of the script being downloaded, work that’s easy to miss.
    - 6y ago
zamadatix 6y ago
I wouldn't say all speed related perks, CDNs for resources like that are still probably wider (and therefore closer) and faster than whatever is hosting your stuff for most sites. Overall it is a pretty big cut out of the performance selling point though.
jahewson 6y ago
Per-site caching is the new norm. Shared caches are vulnerable to timing attacks that infer your web history. It’s a shame but that’s just the reality of caching. Shared caches were never as useful as claimed due to the large numbers of versions of most resources.
cactus2093 6y ago
It doesn't seem like centrally-hosted resources ever centralized enough to be all that useful. Even for sites that are trying to play ball, there are multiple CDNs so everyone has to agree which one is the standard. Plus everyone has to be using the same version of each resource, but in practice most js tools release so often that there will always be many different versions out in the wild. On top of that a lot of the modern frontend tools and best practices are pushing in the other direction. Out of the box, tools like webpack will bundle up all your dependecies with your app code. The lack of JS namespacing and desire to avoid globals (which is pretty well-intentioned, and generally good advice) means that your linter complains when you just drop in a script tag to pull a library from a cdn instead of using an es6 import and letting your bundler handle it. Typescript won't work out of the box I don't think. Your integration tests will fail if the cdn is down or you have a network hiccup, as opposed to serving files locally in your test suite. And on and on. This is just anecdotal, but I haven't seen most teams I've worked with value the idea of centrally-hosted JS enough to work around all these obstacles.
ogre_codes 6y ago
> It also means that I can remove fonts.google.com from the uBlock blacklist. Yay. If you are downloading fonts from Google, Google harvests your IP and likely the referring site from the request. Even if your browser doesn't sent the referrer, many sites have a unique enough font-fingerprint that Google can figure out where you are.
- aarchi 6y ago
  Would this bypass most Google Font tracking? An extension that makes Google Font requests on behalf of the requesting site and caches the response indefinitely and for all sites, somewhat like LocalCDN/Decentraleyes, but on demand.
  - ogre_codes 6y ago
    That would prevent Google from getting every request. FWIW, I'm not sure how much of an issue this even is. My comment was a hypothetical. Sadly the way Google/ Facebook/ etc operate, I just assume that whatever I think of, they've already done it plus 1000s of other things which would never occur to me.
dathinab 6y ago
> Per-site caching negates the principal selling point of centrally-hosted JS and resources It doesn't or more correctly the benefit wasn't really a think in most cases. I will not start the discussion her again but on previous hacker news articles about this topic you will find very extensive discussions about how in practice the caches often didn't work out well for all kinds of reasons and how you still have a per-domain cache so it anyway mainly matters the first time you visit a domain but not later times and how the JS ecosystem is super fragmented even if it's about the same library etc. etc. > cause it reduces the value that unscrupulous free CDN providers can derive from their "properties". Not really, the value of a CDN is to serve content to the user from a "close by" node in a reliable way allowing you to focus on the non static parts of your site (wrt. to traffic balancing and similar). Shared caches technically never did matter that much wrt. CDN's (but people used it IMHO wrongly as selling point).
- dcposch 6y ago
  Plus, FF can preserve the value by allowing cross domain resource caching as long as the request specifies a hash. That negates the super cookie use case, but still lets you eg. load Jquery from a shared CDN. You get a free security upgrade to go with it.
  - dathinab 6y ago
    > Plus, FF can preserve the value by allowing cross domain resource caching as long as the request specifies a hash. This does not work as you still can have the same timing attacks the hash only helps wrt. source integrity from CDN's but not with chach based time attacks. Still what should be possible without timing attack channels is to de-duplicate the storage of resources (through not easy and likely not worth it for most use-cases). So you will only lose the most times small speed post on the load time when you open a domain the first time.
TheRealPomax 6y ago
This sounds overdramatised: caching once for a website you frequent still works just fine, with all the speed benefits on subsequent loads. You're definitely not going to be noticing that the browser now has to build a few more caches than "just the one".
madeofpalk 6y ago
IIRC browsers (chrome and/or safari?) haven’t cached assets like that cross origin for years.
- sgustard 6y ago
  That's cache partitioning in Chrome. https://developers.google.com/web/updates/2020/10/http-cache-partitioning https://developers.google.com/web/updates/2020/10/http-cache...

by abcd_f 6y ago

kristofferR 6y ago

LocalCDN is an extension I would recommend, both for privacy and performance reasons. https://www.localcdn.org/ https://www.localcdn.org/

milofeynman 6y ago
Decentraleyes is what I use. I assume they're similar https://addons.mozilla.org/en-US/firefox/addon/decentraleyes/ https://addons.mozilla.org/en-US/firefox/addon/decentraleyes...
- kristofferR 6y ago
  LocalCDN is an updated fork of Decentraleyes. Decentraleyes hasn't been updated in ages, has few assets and its assets are massively out of date. https://git.synz.io/Synzvato/decentraleyes/-/tree/master/resources https://git.synz.io/Synzvato/decentraleyes/-/tree/master/res... vs https://codeberg.org/nobody/LocalCDN/src/branch/main/resources https://codeberg.org/nobody/LocalCDN/src/branch/main/resourc...
  - takeda 6y ago
    My Decentraleyes was updated in November 5th, that's not that long ago. LocalCDN extension has also a comment that Mozilla doesn't regularly monitor it for security.
    - Forbo 6y ago
      LocalCDN is much, much more actively developed than Decentraleyes. https://codeberg.org/nobody/LocalCDN/commits/branch/main https://codeberg.org/nobody/LocalCDN/commits/branch/main vs https://git.synz.io/Synzvato/decentraleyes/-/commits/v2.0.15 https://git.synz.io/Synzvato/decentraleyes/-/commits/v2.0.15 I'd imagine if LocalCDN got more popular than Decentraleyes, it would probably get Mozilla's seal of approval as a "recommended" extension. Then again I'm not entirely sure what their approval process for that looks like. Currently Decentraleyes has about 100x the userbase.
- deleted 6y ago
  [deleted]
nunez 6y ago
Wow. This is really neat. I’m going to give this a shot!

PaulHoule 6y ago

That idea of having JS files hosted elsewhere always struck me as a Girardian scam (e.g. "everybody else does it") and always getting voted down when I showed people the reality factor. Nobody seemed to think it was hard to host a file before this came along, just as nobody thought it was hard to have a blog before Medium. Of course this creates the apocalyptic possibility that one of these servers could get hacked (later addressed with some signing) but it's also not easy to say you're really improving the performance of something if there is any possibility you'll need to do an additional DNS lookup -- one of the greatest "long tails" in performance. You might improve median performance, but people don't 'experience' median performance in most cases (it goes by too fast for them to actually experience it), they 'experience' the 5% of requests that are the 95% worst, and if they make 100 requests to do a task, 5 of them will go bad. People are miseducated to think caching is always a slam dunk and sometimes it is but often it is more nuanced, something you see in CPU design where you might "build the best system you can that doesn't cache" (and doesn't have the complexity, power and transistor count from the cache -- like Atmel AVR8) to quite a bit of tradeoff when it comes to 'computing power' vs 'electrical power' and also multiple cores that see a consistent or not view of memory.

sanxiyn 6y ago
It's not about being hard, it's about being convenient. Convenience is important. Even trivial convenience.
mdavidn 6y ago
Browsers can check "subresource integrity" to guard against hacks of third-party services. https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
- nunez 6y ago
  Yeah but you, the developer, need to provide the hash of the script being downloaded, work that’s easy to miss.
  - 6y ago

zamadatix 6y ago

I wouldn't say all speed related perks, CDNs for resources like that are still probably wider (and therefore closer) and faster than whatever is hosting your stuff for most sites. Overall it is a pretty big cut out of the performance selling point though.

jahewson 6y ago

Per-site caching is the new norm. Shared caches are vulnerable to timing attacks that infer your web history. It’s a shame but that’s just the reality of caching. Shared caches were never as useful as claimed due to the large numbers of versions of most resources.

cactus2093 6y ago

It doesn't seem like centrally-hosted resources ever centralized enough to be all that useful. Even for sites that are trying to play ball, there are multiple CDNs so everyone has to agree which one is the standard. Plus everyone has to be using the same version of each resource, but in practice most js tools release so often that there will always be many different versions out in the wild. On top of that a lot of the modern frontend tools and best practices are pushing in the other direction. Out of the box, tools like webpack will bundle up all your dependecies with your app code. The lack of JS namespacing and desire to avoid globals (which is pretty well-intentioned, and generally good advice) means that your linter complains when you just drop in a script tag to pull a library from a cdn instead of using an es6 import and letting your bundler handle it. Typescript won't work out of the box I don't think. Your integration tests will fail if the cdn is down or you have a network hiccup, as opposed to serving files locally in your test suite. And on and on. This is just anecdotal, but I haven't seen most teams I've worked with value the idea of centrally-hosted JS enough to work around all these obstacles.

ogre_codes 6y ago

> It also means that I can remove fonts.google.com from the uBlock blacklist. Yay. If you are downloading fonts from Google, Google harvests your IP and likely the referring site from the request. Even if your browser doesn't sent the referrer, many sites have a unique enough font-fingerprint that Google can figure out where you are.

aarchi 6y ago
Would this bypass most Google Font tracking? An extension that makes Google Font requests on behalf of the requesting site and caches the response indefinitely and for all sites, somewhat like LocalCDN/Decentraleyes, but on demand.
- ogre_codes 6y ago
  That would prevent Google from getting every request. FWIW, I'm not sure how much of an issue this even is. My comment was a hypothetical. Sadly the way Google/ Facebook/ etc operate, I just assume that whatever I think of, they've already done it plus 1000s of other things which would never occur to me.

dathinab 6y ago

> Per-site caching negates the principal selling point of centrally-hosted JS and resources It doesn't or more correctly the benefit wasn't really a think in most cases. I will not start the discussion her again but on previous hacker news articles about this topic you will find very extensive discussions about how in practice the caches often didn't work out well for all kinds of reasons and how you still have a per-domain cache so it anyway mainly matters the first time you visit a domain but not later times and how the JS ecosystem is super fragmented even if it's about the same library etc. etc. > cause it reduces the value that unscrupulous free CDN providers can derive from their "properties". Not really, the value of a CDN is to serve content to the user from a "close by" node in a reliable way allowing you to focus on the non static parts of your site (wrt. to traffic balancing and similar). Shared caches technically never did matter that much wrt. CDN's (but people used it IMHO wrongly as selling point).

dcposch 6y ago
Plus, FF can preserve the value by allowing cross domain resource caching as long as the request specifies a hash. That negates the super cookie use case, but still lets you eg. load Jquery from a shared CDN. You get a free security upgrade to go with it.
- dathinab 6y ago
  > Plus, FF can preserve the value by allowing cross domain resource caching as long as the request specifies a hash. This does not work as you still can have the same timing attacks the hash only helps wrt. source integrity from CDN's but not with chach based time attacks. Still what should be possible without timing attack channels is to de-duplicate the storage of resources (through not easy and likely not worth it for most use-cases). So you will only lose the most times small speed post on the load time when you open a domain the first time.

TheRealPomax 6y ago

This sounds overdramatised: caching once for a website you frequent still works just fine, with all the speed benefits on subsequent loads. You're definitely not going to be noticing that the browser now has to build a few more caches than "just the one".

madeofpalk 6y ago

IIRC browsers (chrome and/or safari?) haven’t cached assets like that cross origin for years.

sgustard 6y ago
That's cache partitioning in Chrome. https://developers.google.com/web/updates/2020/10/http-cache-partitioning https://developers.google.com/web/updates/2020/10/http-cache...