I'm not willing to hand over the security of my websites and privacy of my users to a third party, in exchange for my first page load to be fractionally shorter for a small number of my visitors.
Googles jQuery hosting is now a highly desirable target and I don't want to be included in the victims if it does get attacked. We learnt earlier this year how Google can be hacked.
If Google's CDN were hacked (as unlikely as that is), it's almost certain that you'd find out about it far sooner than if your own server were hacked. There would be a huge controversy and then it would be quickly fixed, probably in the course of hours or minutes, just like with the Twitter CSRF issue this morning.
Conversely, the Internet is absolutely littered with compromised sites that have been modified to inject malicious scripts.
That's not a very high cost. They don't choose to hit you, they let their scripts and botnets look around for old and vulnerable software.
Have you looked at your raw httpd logs? When I look at mine, and grep away known-cookies, I see that I'm frequently scanned by hundreds of IPs looking for vulnerabilities in common software packages.
And that's just the stuff that shows up in logged HTTP queries. I don't want to think about how likely it is that tools like nessus are constantly being scan-run against IP ranges that I sit within.
Ok, sure, you can believe you're going to be more on top of things keeping your site secure than a high-value target like Google. I don't know how the target value of your site, but I doubt it's as high as the server the jQuery plugin you're afraid of pulling remotely sits on--and you can bet that Google knows they have high-target-value externally-facing assets, and are watching them even harder and with more eyes than you would.
The thing we're discussing here is whether jquery.js is stored on my server with the rest of my website, or some other third party server. I'm not sure how the things you've said above apply to this discussion?
You were critiquing the security cost of hosting on your own server verses that other server. It was pointed out to you that the admins of that other server would likely learn of (and react to) a breach on their end at a lower latency than you would for your server.
You implied that the security cost for hosting on your server was actually lower, because you weren't as much of a target. My reply was an attempt to point out to you at a technical level why that was a specious argument; your servers are likely being scanned by the same botnets that are scanning mine with automated exploit attempts against old and vulnerable software, and common errors in securing a server.
It's going to be far easier and cheaper for them to take a shotgun-scanner approach against a large class of average systems than to apply manual, concerted effort against a small set of high-value targets like CDN nodes.
The cost to the attacker to attack your system with automated tools is near nil. They'll attack, and if they get in, that's gravy. Using "we're not a target" as a security model makes about as much sense as putting an unpatched Windows box in your home router's DMZ.
I think the part I may have misunderstood was where you said, "With Googles CDN, they have to hack either my website, or Googles CDN.", and I interpreted that as an exclusive condition, rather than an inclusive one. Probably the "either" that did that.
With that misunderstanding corrected, I believe you're generally correct on the security argument. There's still some plausible variation in terms of server security policy and implementation of things like intrusion detection, (Is it safer to keep all your money in your home, or is it safer to keep most of it in a safe deposit box in a bank?) but that's not the key problem I thought I noticed in your argument, and not one worth devoting energy into.
Googles jQuery hosting is now a highly desirable target and I don't want to be included in the victims if it does get attacked. We learnt earlier this year how Google can be hacked.