JsDelivr – The advanced open source public CDN
hacks.mozilla.org
hacks.mozilla.org
1. Access to your users' browser details (via request headers).
2. Access to your users' habits (via the referrer header).
3. The ability to replace executable code. (This code can be used to gather more data from the state of the web page (e.g. keystroke logging), or break out of the browser sandbox and compromise the whole system. Note: this only applies to JavaScript.)
4. The ability to break your software, either intentionally or unintentionally, by not serving the resource at all.
I think there is a sense among good-hearted programmers that "But gosh, they wouldn't do [1-3]! These CDNs are just a really nice public service by companies that care about keeping the web community healthy and fast. And besides, if they ever abused their access to user data, there would be hell to pay!"
Unfortunately this blasé attitude about user privacy on the part of programmers is why we have such a rough time with privacy in general these days. I believe that if you're a programmer with any interest at all in protecting your users from bad actors, that you'll do your best to avoid using 3rd party hosts, especially for executable code.
What's worse is when you see sites running JavaScript from multiple analytics companies, social media companies, and CDNs - even on pages that should be private (login forms, personal details, etc.). It's even worse when those sites break without those scripts. This is a concern that far too many developers overlook. I made this (harsh) comment [0] on such a site posted to HN a few months ago.
CDNs are way overrated, from what I've seen. I think, for most use cases, you're better off avoiding the multiple HTTP requests and just compressing all your JavaScript into a single file. Serve that from your own server and you'll save the client from another domain name resolution too.
Do yourself a favor and install NoScript. For one thing, it will show you how easily Google can (or, could have) track your internet usage - and, as you pointed out, so much more. In my experience, about 50% of sites serve scripts from some Google domain.
What's remarkable to me is how ubiquitous and unquestioned the use of CDNs has become.
BTW NoScript/Ghostery don't address the CDN issue. They don't actually block CDNs, they just block explicit trackers (mainly in the forms of iframes and scripts linked to known-bad hosts).
I don't know much about Ghostery - NoScript addresses most of my privacy concerns around web browsing.
http://daemon.co.za/2014/03/from-trenches-js-cdn-point-of-fa...
Basically, if you need to include something like jquery, you have to have code that makes use of it. Since by definition, you can't serve that code from a public cdn, you are going to need to serve those static assets somehow.
I now believe that you should serve the vendor code from the same 'place' as you serve your application's static assets, because by relying on external resources, you are adding more moving parts that all have to be in perfect working order for your app to actually be able to run.
This doesn't really have anything to do with how reliable the CDN itself is, but rather with how reliable the client's connection is.
I did read the jsdelivr post, and it actually looks like a really well thought out system. I just don't think I will use something like this for anything where I have the choice not to.
IMO, the possible benefits of using a public CDN, don't outweigh the fragility that gets added. It just feels like it is trying to optimize best case performance while worst case is far more important.
I'm not against CDN's as a concept though, I just think you should serve all the code that is needed for normal operation from the same one.
> This doesn't really have anything to do with how reliable the CDN itself is, but rather with how reliable the client's connection is.
If they have the CDNed version of jQuery cached then it doesn't need their connection to do anything.
it can take several seconds for the request to fail, during which your application won't have been loaded or working.
the fallback adds complexity to your code, which ultimately didn't need to be there.
I just think that it's better to reduce the ways that your application can break, before trying to make it a little bit faster for the cases in which all the conditions are met.
On principle, even in the theoretical best case scenario, I think it's not the right approach to be taking.
I also don't think that the best case scenario can be reliably enough predicted to be something you should try to optimize for. There are many CDN's, many different versions of the many different libraries. Especially on mobile devices, cache size is limited.
IMO, at least.
the http request the cdn to get the file is not a 'free' operation. network timeouts take time.
I'm working on a project that uses google fonts and the page loads with fonts timing out multiple times per day. I get to sites where just the html loads and none of the css (or worse: just some of the css) all the time. Especially on 3G, but regularly on ADSL too. Or what if you're sharing a saturated line?
(And waiting for a timeout to kick in before you trigger a callback is just not an option. By then the user probably closed the page anyway. Rather just make it work in the first place.)
But if the client already has it cached it doesn't even make a request. CDNs have long expiries because the content of the JS lib will never change.
There are many CDN's, many different versions of the many different libraries.
But you're only using one.
Especially on mobile devices, cache size is limited.
All the more reason to use a CDN.
There are so many public cdns now and so many versions of libraries scattered about that the chances that the user already has the resource cached is rather slim.
Your build tool might as well have combined it all and sent the same "cache this forever" header. And in the common case that would have come from the same host as some other files, so one dns lookup, one http connection.
I think public CDNs optimise an edge case for little benefit. But maybe it is clearer to me because I always have high latency where I live and my connection speed can be described as "medium" at best. I see sites only load some of their resources due to splitting files across CDNs on a daily basis.
I can understand that if you have a sub-20ms ping time to your local CDN and a cable modem this might be difficult to understand.
Making everything work or everything fail together is a lesson I've learned many times.
or fail consistently at the same time if your server isn't accessible. In that case it doesn't matter that the public cdn is still accessible.
i just don't think the possible benefit of public cdn hosted code can justify how many moving parts it adds.
If my server is not available, my web application will ultimately fail anyway.
https://developers.google.com/speed/docs/best-practices/rtt#...
For the large libraries we use that are hosted on a cdn, with a local fallback, we use the :empty value for the optimiser and they are exclude from our modules.
For the rest of the users, there are three cases:
- the user has accessed the application in the past (or any other webpage that uses the cdn): a cached version of the library is served by her browser. - the user has never accessed the page, the cdn is unavailable:
* either the Internet connection has failed, and our application won't be available anyway * the cdn is indeed down, the user has to wait for the timeout before her browser fetches the local fallback.
The third case sounds extremely rare (look at the statistics of major cdns out there, they often have better uptime and response time than your own servers). And the advantages provided by the first case do more than compensate in my opinion.
> Who is behind jsDelivr?
> Basically just me, Dmitriy A. or @jimaek. But a lot of other people are involved, giving their advice and helping me out. I always refer to jsDelivr in the plural sense because of this.
It is sponsored, amongst others, by CloudFlare and MaxCDN, where @jimaek is also employed. But the only connection to Mozilla seems to be that it's featured on the Mozilla Hacks blog.
Personally, I don't trust such services any more than I trust cloud hosting, which means not at all. I have no way to make sure that they server these files unmodified, that they aren't neglecting their servers to the point where they're hacked and serve malware to my users etc. ...
For CloudFlare and MaxCDN I have 2-Step authentication enabled + for MaxCDN 1 allowed whitelisted IP address.
Regarding unmodified files I guess we can build an app to monitor them? If you want drop by https://github.com/jsdelivr/jsdelivr and we can discuss this even further.
I would be happy to do anything possible to ease your concerns regarding security.
I had a problem with cloudflare inserting some tracking cookies into my static HTML files. They claimed it was ddos protection. To me (and the EU cookie directive) it looked no different from the garbage other analytics sites use.
If jsdelivr providers are allowed to modify the files they serve, I won't use it. Got any sort of guarantees?
Thanks.
MaxCDN does not modify the files in any case.
I will be in contact with them to make 100% sure the fix wont be reverted in any case.
Sometimes, the stuff they inject also has horrible bugs ;P. One time, for an entire day, they were managing to lock up Safari entirely. Cydia is mostly a web browser, and one of the companies I work with apparently used CloudFlare, so Cydia suddenly stopped working that day in a way that was pretty catastrophic. I did a writeup on the process of discovering the bug (which I had to report to CloudFlare to get fixed: I don't even think they really had the expertise in-house to figure out what happened).
I mean, what's to stop this scenario: 1. attacker uploads a poisoned version (say, with an XSS vulnerability) of a popular library to an official-sounding github repo 2. attacker raises a github issue with you asking you to put it on jsdelivr 3. you assume the attacker is a legitimate contributor or user of the library and add it to jsdelivr 4. other sites start using the poisoned version of the library 5. attacker can now carry out XSS attacks on the sites using the library
I have another security concern about www.jsdelivr.com (which I hope is totally separate from the CDN?) but I'll email that to you.
But once the auto-update app comes online this issues should become obsolete.
www.jsdelivr.com is completely separate from the CDN. Plus the code is open sourced so you can actually see how it works.
There are no technical measures that can prevent you or the companies hosting these files for free from serving modified JS arbitrarily, or on some authority's demand, to everyone or to selected individuals. If we could put a checksum in the <script> tag, we'd be fine (to some extent, provided collisions are really hard to find - so no md5 please), but we can't, so we aren't.
Like many other web site owners, I believe security to be more important than my bandwidth or a few 10 more miliseconds of loading times, so I can't be convinced easily to use a public CDN for JS.
(and yes, I still have to trust other people for not backdooring other software and hardware I'm using, but I try to keep the attack surface as small as possible)
We are in excellent relations with all of our sponsors so no issues there.
For the rest stuff like Domains, SSL, Hosting, Freelancers, other I pay myself.
Maybe someone could convince them to adopt your multi CDN technology for web fonts? The reason why I want this is because in China the GFW periodically hangs connections to Google's IPs after searching certain keywords for 90 seconds. This causes any site that uses Google web fonts to hang until the connection is resumed.
I guess Google is the one who knocks :p
You can't put your static files on that public cdn. So either you have to serve it up yourself or you have to put it on your own CDN (either one you run yourself or a managed one).
So you have an additional point of failure (because your static files are coming from at least two places rather than one) which multiplies the chances of something going wrong for little benefit in my opinion.
Deployments are likely to be much more complex too, etc.
And before someone mentions the limit of how many concurrent requests a browser will make to a host: That's also irrelevant. I'm not arguing that you should have loads of little files. You should still be combining things with build tools. In fact if you host those "vendor" files on your own webserver or cdn you actually have more flexibility around how to combine them. And you can still have multiple subdomains and ip addresses or whatever pointing to the same CDN to try and optimise around that if you want.
EDIT: I wonder if the multiple-request URL's mean that the individual assets won't be cached, which is a big selling point of CDN's.
(Though there's debate as to how much that matters.)
I regularly submit new libraries and update the current ones through their Github repository.
The multiple files per request is nice however, but contributing to cdnjs might have been a better way of proposing it.
Akamai is cadillac of the CDN world so more like Apples and Organic Gourmet Apples.
Rather then having the latency between the client and the server, you'd instead have latency between the two servers.
No. If you design the game properly, they actually don't have to coordinate very much at all.
So what is 'Js' about it? Has 'i' prefix become old-fashioned?
But we still want to help open source projects to take advantage of our network. This is why we allow even windows binaries and other stuff too.
Mistakn usrs somtims correctd missd lettrs, so thy downloadd pags from unrelatd servrs.
Howevr, the spc thy postd mentiond othr use cass, and presentd exampls of anothr systm with enterprisy qualitis to delivr usrs to correctd wb sits with misspelld nams:
A clevr browsr evn maks guesss, which enabls fils with unrequestd but correctd nams to be downloadd in paralll ovr integratd distributd per to per technologis, oftn receivd replis cachd, and latr presentd.
Ys, yt again, browsrs designd by committs enabld Opn Sourcs and Fre Softwars to answr anothr complicatd Internt problm!
https://cdn.jsdelivr.net/g/jquery@1.10.2,bootstrap@3.0.3,angularjs@1.2.10
Also, it's not clear if you can or not mix CSS and JS in the query, that would be neat to do that and then to insert CSS with Javascript (or maybe that would be a bad idea).
You can mix CSS and JS in one query but its up to you to make it work.
To load Bootstrap CSS you need to specify the exact file like so
https://cdn.jsdelivr.net/g/bootstrap@3.1(css/bootstrap.min.c...
Because the main file for this project points to a js
Here is my final Javascript query: https://cdn.jsdelivr.net/g/jquery@1.10.2(jquery.min.js),boot...
You need to specify the files if you are loading files other than the one specified in the "mainfile" parameter. Or loading multiple files together.
Most of the libraries I use are already on there, and I like the fact that brief glance information is shown for each library. Also noticed there's a duplicate misspelt typeahead library listed.
We are also thinking new ways to add files https://github.com/jsdelivr/jsdelivr/issues/347
We need to maintain our own structure to allow features like file grouping and version aliasing.
Leaking what? Your publicly available JS libraries? or is this a more general Mozilla bashing comment?
The service itself looks great, and the versioning is exactly what I'm after.
I guess, browsers could provide a separate cache for CDN domains that's _really_ long lived (there's a certain guarantee that files won't change there) and also send requests there with no referer at all times.
Requesting assets from third-party websites leaks that I have been visiting your site to the third-party. Now imagine having a big CDN that many websites use and you can spy on a lot of unsuspecting users.
If you don't want someone to have this information, the sensible thing is not to offer it. I cannot conceive of any way in which sending the information and then yelling at the recipient for receiving it is "more correct" than just not telling people things you don't want them to know.
Web developers have a responsibility to protect their users from threats they don't even know exist.