

Microsoft's Ajax CDN tumbles worldwide - fabm
http://www.zdnet.com/microsofts-ajax-cdn-tumbles-worldwide-7000009333/

======
dotBen
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...](http://media.blackhat.com/bh-
us-12/Briefings/Alonso/BH_US_12_Alonso_Owning_Bad_Guys_WP.pdf), 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_

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

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

~~~
kamjam
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>

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

------
Benferhat
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/>

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

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

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

~~~
crescentfresh
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>

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

~~~
crescentfresh
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>

