CDNJS: The Fastest Javascript Repo on the Web
blog.cloudflare.com
blog.cloudflare.com
Not only is it 2.5KB of extra header info sent, but I don't think cloudflare should know which websites their customers have been visiting.
I don't see a privacy policy on CDNJS.com. I'd definitely like to know what data they collect about my visitors and what they do with it.
At least the CDN doesn't itself set any cookies.
And note too, that if you're relying on a 3rd party to serve javascript your users are going to run in their browsers - if that 3rd party isn't trustworthy, you're screwed in much worse ways that cookie tracking privacy violations. Who'd notice if they started occasionally serving a modified version of jQuery which sent all form field keydowns (aka, your usernames and passwords) back to theselves?
I think my comment above was too paranoid, as well, but it's too late to edit. All I was suspicious of was that there might be analysis going on.
How does CloudFlare make its money? It's a CDN company. I mean, that's the CORE of what they do. What is jsCDN? It's a CDN.
A simpler theory is that hosting a Javascript CDN (and demonstrating that it's even better than Google's, which is amazing), is going to provide a lot of free advertising for their product. If I use their CDN for JS and it works really well, I'm likely to go back to them for hosting other things, because using jsCDN is almost like doing a free trial of their actual CDN.
It's not even like their main form of income is in another industry that we have to make a cognitive leap to see what their ulterior motives are. It's precisely this. CDNs.
Definitely not very useable for tracking purposes, they will only know about first visit of a user. Even more if sites a and b use the same js library and version, they will only know about the first that a user visit.
Anyway is a bad technical decision not to use a different domain to ensure clients don't need to send extra cookies in the headers.
Though for the most part, people will not have cookies set on the domain unless they have visited the main site (i.e. they are developers).
Or would that mess up cloudflare's anycast DNS?
Thanks to Ryan, Thomas, and CloudFlare for a very cool service!
So, wouldn't it be better to go with the most popular and not the fastest?
I really don't know how anyone can take CloudFlare seriously anymore...
https://github.com/cdnjs/cdnjs#pull-requests-steps
While Google and Microsoft are slower to update their libs, we can assume that they are downloading releases from official sources.
If not we track down the official repositories ourselves.
Once we have verified the source, we then check the diff against the submitted and official. We have always flirted with the idea of a level of automation to handle this. But your comment addresses the problem with a solution such as that so we are still manually diff checking for maximum security.
Usually in every project there is bunch of .js [jquery, backbone, etc] and .css files. So the good practice is not only to minify and compress, but also to bundle some/all of them into several big combined files to save on extra HTTP calls.
So my question is - what is better - (1) have separate files served from such CDN [or any public CDN] or (2) combine the files and serve yourself by nginx/AWS?
Not a developer, feel free to correct any mistakes :-)
Even happier to see that you guys host CSS and images for the common libs. I will change my bootstrap css hosting over to yours soon.
a) would require all servers and browsers to be updated for what is a marginal gain
b) privacy nightmare
except the part where you track people across sites
what I am saying is not speculative. this has been proposed previously, and shot down. there is a reason why it hasn't happen.
The browser vendors just spent the past 4-5 years locking down cross-origin access in the DOM because of all the security and privacy implications that come up. Corporate profiles and ISO standards don't even accept running the code - let alone caching it (i've worked on plenty of corporate projects where you aren't allowed to even use Google hosted JS - it just won't run due to AD policies).
To give you but one example of what arises with this new vector. Say I were to go to the top 50 banking sites and take a sample of a Javascript file that is unique to each site. I would then take the hash of each file, and in a single web page include the script element with a hash of each of those files. When a visitor hits that page and the browser attempts to load each script element, if it loads it in 4ms then I know the file was in the cache and that the visitor is a customer of that bank.