If anyone still needs convincing these CDN'd JS lib are a bad design pattern, check out this presentation from 2012's Black Hat (and also DEFCON) on MITM attacks on them that persist after the user has been exposed (due to indefinite caching of poisoned JS files).
the tl:dr is users browse a short time via an anonymous proxy (c'mon, many do), the proxy MITM's these CDN's JS lib requests and serves up poisoned versions that work but also check a mothership server to load in further poisoned + persistently cached JS files for popular websites (banking, facebook, etc). User then ends their proxy session but future visits (even direct, not via proxy) to sites loads in the now cached poisoned JS libs. Phishing, credential theft, clipboard theft, etc is all now possible
How often does your average user browse via an anonymous proxy? I doubt most would even know what the hell you are talking about. I can understand for your more clued up or power user, but you give the average user too much credit.
Every time they use a public wifi hotspot. Any time you use a network you don't control and where you have no reason to trust the admin, you may as well be using a proxy.
The requirement to trust the admin isn't about the admin MITMing you, but rather trusting their competency in preventing other users MITMing you. Of course the admin could be bad as well.
In your local starbucks? Probably very rarely. In the VIP business lounge of an major international airport? I wouldn't be so sure in this day and age...
In the cafe on the corner of your block in syria, iran and similar places though, the odds are a lot better.
I set up a VPN server at home on an old laptop, it works well for me in these scenarios (also for location-blocked services like Netflix while travelling out of country).
Yeah that's a good point, the # of those users is going to be high in that user sampling (black hats), but very low for most of the rest of the world. I think I used an anonymous proxy back in '02 to get around a forum ban or something.
Well I've added CDN failure contingency to my todo list for the site I'm currently running. The lack of communication from Microsoft is annoying, even a tweet acknowledging the issue would be something.
More generally, I have never understood why people use these third party CDNs for important sites. Don't get me wrong, I understand the bullet points that the Microsoft's and Google's trot out: User more likely to have it cached, more simultaneously open connections since it's a different domain, perhaps less latency etc.
But the simple fact of the matter is if the CDN goes down, your site essentially goes down. Everything else might be up and working great, but how well will the UI function if the user can't pull in jQuery? I just don't see any value in taking a dependency on these third parties for hosting JS libs and the like.
Correct on both counts. One con of hosting multiple dependencies locally could be that parallelization of downloads is reduced. There's always a flipside and each situation warrants analysis!
I think for popular CDNs hosting popular libraries(google's jquery for example), the browser would use the local cache. So, I imagine there's a benefit to using a big CDN for those cases.
Yes I've found that too. Our single-page-style apps would do better to bundle all our dependencies together into a single request to our own servers.
However say for content-based sites, the theoretical ideal is that the content should be delivered and usable without the inclusion of fooLib.js (which folks say should even be included as late as just before </body>), so a delay from a CDN would not necessarily cause any apparent "hang". Again this is the ideal and admittedly I've never got it right.
You could probably wire something up in JS to handle it with reduced timeouts, e.g. an AJAX call that automatically fails after 50-100ms and proceeds to load the local version.
A simpler solution would be to reload the page passing a parameter that you want to use other CDN; something like this: https://gist.github.com/4444636
You've now got people wondering why their page just reloaded after half a second and a slug of unnecessary javascript in your page all for the sake of simplicity.
A simple solution would be to just link to a self-hosted version of the lib.
Yeah, I know - but why bother? Just host the libs yourself and be done with it. Plus that way you can bundle them with your other scripts and save a request.
Edit: To clarify - the reason I don't like the above solution is because if the CDN is slow to respond for some reason, you've just wasted a bunch of your user's time before loading your self hosted version.
> bundle them with your other scripts and save a request
There's huge merit in that IMO for single-page type applications that have many lib dependencies.
For content-based pages (dunno what to call them, whatever the opposite of single page apps are) the benefits stated by Google/others are more apparent with the CDN with local fallback approach.
I figure most content sites that are including jQuery are likely including some other third party libs. In the case of more than one external lib I think bundling makes sense and has a positive impact.
Well; I also think this is going offtopic but I have to mention "unescape" is not a JS standard but it is available in most JS engines; in the other hand literal Unicode codes in strings are part of the ES specification.
I think the idea is that hosts like Google (and ostensibly, Mircosoft) are going to have availability that far exceeds your run-of-the-mill website. Those big hosts generally are going to provide five 9's (or more) availability, whereas %your_random_site% is probably going to be on the order of three to four 9's, at best. So more often than not, the point of failure is going to be your website...not the CDN.
If you have the infrastructure ($$$) to support your own web services on the order of 99.999%+, then by all means host it yourself, otherwise you're most likely never going to have a problem with it (especially if you include a fallback method).
I'm not sure I follow. Obviously if my host goes down my entire site will go down - this is not the point. The point is that when my host is up, what % of the time will my site still be down? Well if you use a CDN that % is greater than zero. If you use two CDN's the percentage is compounded.
I don't understand this logic entirely. If your site is unavailable due to normal, unavoidable probabilities in reasonable uptime, why does it matter if the CDN is hosting your scripts or not? Your site isn't going to be around to access them.
It doesn't matter in those cases; it DOES matter for the 99%+ of the time that both the CDN and your site are working optimally. In theory, the CDN should provide the best all-around experience for users (caching, lower latency, parallel loading, etc.). THIS is why you have the CDN -- not as some fail-safe for when your site goes down.
I agree completely that your average website will have less uptime than the CDN. The problem isn't that the CDNs are less reliable, it's that it's VERY unlikely that your site will experience downtime at the same time as the CDN. This means your site reliability is the combination of the downtime of the CDN as well as your own.
See the rest of the comments in this thread about why the fallback can be painfully slow if the CDN is down. I saw your previous comment about making an ajax request with an adjusted timeout, but this is not ideal for making cross domain script requests for a number of reasons. For one, CORS needs to be enabled. Another is that you now have to create a script tag and take the responseText and jam it in there. This is going to be slower than just creating a script tag and setting the src attr.
If you are going to have a fallback, and that fallback may take seconds to activate if the CDN is down, why not just make the fallback your primary?
This was what I was going to suggest also... but...
Whatever happened to using progressive enhancement techniques which meant the site would continue to work, albeit with basic functionality, for users even without JavaScript?
I understand for some sites this is not possible, but for a lot of sites it would be perfectly acceptable...
This is exactly my thought on the matter. It's cool that larger sites will host these scripts for you, but why should I make my site dependent on another just for a negligible improvement in speed / caching efficiency?
My feeling is that if you're going to make your site's uptime dependent on another, at least make it for something worthwhile that you can't host yourself, either because it's too demanding or too proprietary.
"More generally, I have never understood why people use these third party CDNs for important sites."
Perhaps its not a core-competency of the company? When you're a small company you only get a few employees to work with maybe none, so you find ways to get the stuff you don't know how to do, done. Whether its contract work for design, or outsourcing operations to the cloud.
http://media.blackhat.com/bh-us-12/Briefings/Alonso/BH_US_12..., or https://www.youtube.com/watch?v=ZCNZJ_7f0Hk (quite entertaining presentation)
the tl:dr is users browse a short time via an anonymous proxy (c'mon, many do), the proxy MITM's these CDN's JS lib requests and serves up poisoned versions that work but also check a mothership server to load in further poisoned + persistently cached JS files for popular websites (banking, facebook, etc). User then ends their proxy session but future visits (even direct, not via proxy) to sites loads in the now cached poisoned JS libs. Phishing, credential theft, clipboard theft, etc is all now possible