Generalizing this out just a little bit: please be aware that when you source Javascript from places like TypeKit or Crazyegg or whatnot, you're setting the security of your web app at the lowest common denominator of all those sites.
It's not just a question of whether the script they're providing you today is safe; it's a question of whether their own applications are sound enough to prevent an attacker from popping them and changing what the script says.
I think the modern vogue for sourcing Javascript from random API providers is a bad idea; I predict that the badness of that idea is going to become more and more evident over the next few years; I think you'd be well-served by investigating how much of that stuff you can serve directly.
Because every page in the app is bound to carry the jQ dep, and you can just as easily provide your own static file hosting for jQ. It seems like a pointless complication to the security model of an app, to take its core Javascript framework library and host it offsite.
This question is nonsensical. If you can't host a static file you are screwed no matter what. We can argue about how much of a risk Google CDN is (I don't think it's much of one), but it's not zero.
No offense, but from my perspective you're getting a little rude here without really explaining the situation.
So far I grasped from you that external static files compromise the security model so much it's worth the time and effort to keep up to date with them locally and be okay if the page load times suffer (they do especially with minimalist sites.)
I understand the risk that Google CDN might be hacked and turned into a data mining monster, but it would, at the same time, infect so many important and popular sites on the whole web, I can't even imagine my sites being targeted.
but it would, at the same time, infect so many important and popular sites on the whole web, I can't even imagine my sites being targeted.
Maybe, or maybe it's exploited to target only your site by detecting referrers and only serving your site malicious javascript. Thomas is correct in arguing to host your own.
Lots of sites use Google's CDN so it's very likely the file is already in your user's cache. That seems like a nice little speed bonus if the only trade off is the theoretical risk that Google's CDN might be more easily hacked than your own server.
As an aside, I notice on my site there are a few precent of visitors with security settings on their browser that prevent loading from Google's CDN (actually, there's usually an internet security product of some sort interfering). So you're going to have to provide a fallback to a file on your own server anyway.
Of course! Your whole app is hosted on your server, you're already hosting a bazillion images and other files, including scripts and CSS - if your server is compromised it won't matter much whether your jquery.js is safe or not. Also, aside from security concerns, you're adding an unnecessary single point of failure to your project.
Sure, CDNs are advertised as super reliable and stable and whatnot, but all services go down once in a while. As with every monoculture, there will be large scale outages. It's something developers would be better off acknowledging and planning for upfront instead of having a heart attack whenever a service goes down "unexpectedly".
There is a way to fall back to locally hosted version in case the primary one goes down. Still not convinved I should give up on the speed bonus a precached asset gives me.
Thomas wasn't really discussing about this in regards to the external CDN going down he was discussing it in regards to the CDN being a large point of attack with little benefit to your speed increase.
Look at it this way: if google's jquery is attacked and becomes compromised you and everyone else who uses it has become compromised because you were relying on third party security.
Next if you use jquery from google's cdn for the reason of they can do file security better than you you are already fucked because if someone is targeting your specific jquery hosted on your server chances are you are compromised in other ways.
If you want to use it for the precaching you can but I don't think precaching the 100kb jquery is really going to give you that much benefit in the long run, especially if your website is an application or something along those lines.
The worst offenders here are those who host their jQuery and offer it to others on a domain that is also being used to host other web applications.
For eg. company xyz.com is a hosting company, but it also offers jQuery and other javascript at cdn.xyz.com.
A client of the company at client.xyz.com is setting a cookie for its users but sets it as xyz.com. Now everybody else that is using cdn.xyz.com will also see those cookies.
One example of this is the cloudflare CDN[1]. All of their clients and all of their hosted javascript is on the same domain. Test it out by checking the cookies your browser sends along[2], I see random Techcrunch cookies (they used cloudflare on a site)
I think it's important to also notice that attackers (most recently Duqu) are increasingly often using valid certificates. The more parties you trust, the easier it is for an attacker to find a weak link.
It's not just a question of whether the script they're providing you today is safe; it's a question of whether their own applications are sound enough to prevent an attacker from popping them and changing what the script says.
I think the modern vogue for sourcing Javascript from random API providers is a bad idea; I predict that the badness of that idea is going to become more and more evident over the next few years; I think you'd be well-served by investigating how much of that stuff you can serve directly.