[mikemol]

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.

[mike-cardwell]

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?

[mikemol]

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.

[mike-cardwell]

I'm already hosting my own website on my own server. That attack space already exists. You seem to be misunderstanding this.

We're only talking about moving one of my files from my current website to an entirely different third party service over which I have no control...

Do you not understand this? Spreading my website over multiple services controlled by multiple people decreases the security... Obviously...

[mikemol]

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.

[mikemol]

er. "known-cookies"? That was supposed to be "known-good queries." I think it's time to break for lunch...