Microsoft's Ajax CDN tumbles worldwide | Hacker News Reader

Microsoft's Ajax CDN tumbles worldwide

zdnet.com

37 pointsfabm45 comments

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).

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

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.

Yay for never using public wifi hotspots, now if I could only impress that upon the millions of Americans who do so everyday...

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).

Any time you browse via public wifi you might be being fucked with. How often are you actually? My wager, depending on setting, very rarely.

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.

Fair point. But if they have gone to this extent, they could just as easily inject some code into the HTML no?

http://news.ycombinator.com/item?id=3804608

They're talking about what happens when you load an infected jquery.min.js from cache when you get back to your home wifi network.

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.

This is why I use yepnope [0].

"yepnope.js has the capability to do resource fallbacks and still download dependent scripts in parallel with the first."

[0] http://yepnopejs.com/

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.

It looks like the CDN still works from Australia but is down almost everywhere else

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.

CDN, with local fallback:

    <script src="//ajax.aspnetcdn.com/ajax/jQuery/jquery-1.x.x.min.js" type="text/javascript"></script>
    <script type="text/javascript">
    window.jQuery || document.write(unescape('%3Cscript src="/scripts/jquery-1.x.x.min.js"%3E%3C/script%3E'))
    </script>

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.

This is what we had, but it wasn't responding quickly enough, so the site was hanging despite the fallback.

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.

False; because (if the script is inside the head of the page) the loading of Javascript is synchronous so the user will not notice any refresh at all.

Don't use unescape, is ugly and is not required if you break the close tag of "script".

    this.jQuery||document.write('<script src="js/jquery-1.8.3.min.js"></sc'+'ript>')

Yes, also document.write('\x3Cscript>\x3C/script>'). But these are beside the point.

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.

If you do overall page loading times, I wonder what sort of averages you will see comparing this to hosting it locally for all requests.

When hosted locally it would result in 1 less DNS lookup, as well it could reuse an open HTTP connection to fetch the resource.

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!

So many of these discussion points are discussed at https://developers.google.com/speed/docs/best-practices/rtt

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.

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 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.

Yeah, but if you gracefully handle those failures with local fallbacks, then the CDN's downtime is a moot point.

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?

You can easily specify how much time a CDN will have to respond as you can see in my example in another comment: http://news.ycombinator.com/item?id=5003129

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.

And that's why you have a fallback, to fully mitigate any CDN downtime (how little that it may be). It's like a spare tire in your trunk.

If your webserver is down what does it matter that the CDN that hosts your library scripts is up?

It doesn't, but that was never the point of the CDN.....

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.

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.

> My feeling is that if you're going to make your site's uptime dependent on another

That's a terrible idea, and of course you shouldn't do that.

You provide a fallback for the CDN...

"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.

Reply on news.ycombinator.com