Why would anyone use code.jquery.com, really? They obviously don't mind a third party hosting their js, so why not use the most popular service (google) to increase the chances that users arrive at their website with jquery already cached?
Because webmasters would rather compromise the security and integrity of their site, and the privacy of their users, than pay for the initial burst of bandwidth and latency for first time visitors. jQuery 2.1.0 production, minified and gzipped is still over 30KiB, compared to this thinkbroadband page which is only 6 KiB (and yes this page uses about half a dozen external js resources, including jQuery)
Perhaps it's about time we had a way to specify the hash of <script> source inline so browsers can serve files from cache even if they are from different origins
A spec for just that was recently proposed[0], it even has support for a "canonical" script to be used in the event of that the hash check fails.
The good news is a polyfill for this can probably be created today. If CDNs serve their JS with the proper CORS headers, you can request the JS with cross-domain XHR and check it against a hash before eval()ing the script.
The bad news is that the polyfill would require you to allow `unsafe-eval` if you use Content-Security-Policy headers. Depending on your security model, it'd probably be best to host all your resources yourself. Not to mention that using a hash function written in javascript might negate any performance gains.
[0]: http://w3c.github.io/webappsec/specs/subresourceintegrity/
Since the server needs to grant you full cross-origin read permissions to even start the hash check, it's not likely that an attacker could use this to infer more about cross-origin resources than they already can.
[0]: http://w3c.github.io/webappsec/specs/subresourceintegrity/
If you can perform hash preimage attack, then faking a JS library is aiming really low.
• You could forge any SSL certificate.
• You could forge any PGP/GPG message (public key crypto is not applied to whole messages, only hashes of them, same with certs).
• You could maliciously modify Git repositories, even those with GPG signed releases like the Linux kernel.
• You could inject malware into any package repository, MITM software updates for all OSes, etc.
Basically security of the entire Internet and all secure software distribution depends on the fact that preimage attack against crypto hashes is impossible (i.e. time and/or energy required to perform a brute-force attack is literally astronomical).
That certainly feels more inline with how the internet in general was designed.
<script src="googleapi/jquery,code.jquery.com/jquery,/my/own/version/jquery">[0] http://en.wikipedia.org/wiki/Content-addressable_storage
(Yes, it becomes a problem when you use private browsing, since the cache is cleared when you end the session.)
> I want to know what privacy concerns you have regarding static CDNs that you don't implicitly give up by accessing the Internet.
implies that the privacy concerns for 3rd party JS library CDNs are null. They are only null if you don't already block or misdirect their other tracking methods.
They'd be much more likely to know that blocking anything from Google is probably a bad idea/false positive but they've probably never heard of jQuery and when they look at the jquery*.js files all they see is The Matrix.
So if you allow the above assumption, it's less likely that using Google's CDN would present this problem.
There might, just possibly, be a meta lesson here that whack-a-mole blocking doesn't work and is basically a lost cause / waste of time. Try solving the problem another way.
On the other hand, its excellent security theater operating perfectly. Sometimes security is inconvenient, therefore anything inconvenient must be secure, therefore this is great PR.
Regardless of which CDN you use, having a fallback is a must (see rmrfrmrf's post). Also, if you are making a website (as opposed to a web app), it really shouldn't "break" without JavaScript/jQuery.
That's unlikely. Some parental control filters from ISPs were blocking big name childrens charities like Childline. If they blocked that, then that shows they are very incompetent