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.
Huh? Who ever said the main point of a CDN is to make things easier? It's always been in order to provide a faster end-user experience.
> ...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.
But common CDN's will virtually already have their IP address cached while you're browsing anyways.
Caching certainly has nuance to it as you say, but I think you're being particularly ungenerous in claiming that CDN's are a scam and that you're representing "reality".
Businesses measure these things in reality with analytics, and they also almost always analyze the worst 5% or 1% of requests as well, not just the "median".
CDN's are a big boost to performance in many cases. Or at least, until now (for shared files). You shouldn't be so dismissive.
Every byte sent will cost the business. If you can save that 2MB per user per cache life, you pay that much less on the internet bill for your hosting.
Every byte sent uses up some of your limited bandwidth while it is being sent. If your site is 10KB and you rely on 2MB of javascript libraries and fonts, offloading that 2MB is quite a significant reduction is resource usage.
These above two views seem vastly more important than terminal laziness, up-time management, etc.
Ah yes - I remember those _dark days_ of being a shared webhosting customer over a decade ago and stressing about breaking my 500GB/mo data transfer limit.
Today, Azure's outbound data costs on the order of $0.08/GB, so 1MB is $0.000078125, so the cost of 2MB of JS is $0.00015625.
Supposing you have one million new visitors every month (i.e. nothing's cached at their end so they'll download the full 2MB) - those one million visitors will cost you $156.25 in data-transfer.
Compare that to the immediate cost to the business of paying their SWEs and SREs to trim down the site's resources to a more realistic few-hundred-KB, supposing that's a good 2-3 week project for 3-4 people - assuming a W/Best Coast company, that's ( $250k / 52 ) * 3 * 4 == $57,000.
From looking at those numbers, there is absolutely no business case in optimizing web content - it's now significantly cheaper (on paper) to have a crappy UX and slow load-times than it is to fix it.
... then you're doin' it wrong.
100%. Its mind blowing that this could possibly be considered without batting an eyelid.
https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
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.
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).
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.
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.
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.
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.
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/res...
vs
https://codeberg.org/nobody/LocalCDN/src/branch/main/resourc...
https://codeberg.org/nobody/LocalCDN/commits/branch/main vs 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.
It also means that I can remove fonts.google.com from the uBlock blacklist. Yay.