Hacker News Reader

Comment by lazyjones | Hacker News Reader

> I should also point out that MaxCDN, CloudFlare, Cedexis and the rest of the companies sponsor jsDelivr for free.

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. ...

View on HN

I would be happy to address these issues. You have no reason to believe me but all custom servers are secured and are regularly updated.

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.

Do you have any sort of agreement that they will serve these files bit for bit unmodified?

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.

They are not allowed to modify the files. CloudFlare had to deploy a special fix to disable all cookies and security functionality completely on my account. Only after the fix I enabled their CDN.

MaxCDN does not modify the files in any case.

I think with CloudFlare you should really get an agreement that states some kind of penalty if that "special fix" every accidentally breaks (their engineers seem pretty fast/loose with agile code changes that affect their customer's sites).

I think so too. I'm happy and reassured to hear that assets are served unmodified now, but do you have a guarantee that it will remain that way?

Modifying already hosted files is unacceptable. The fix by CloudFlare was a custom code that disables the Control Panel features completely. Even if I or someone else enables it, it wont do anything.

I will be in contact with them to make 100% sure the fix wont be reverted in any case.

FWIW, the only "CDN" I've ever heard of to regularly pull stunts like that is CloudFlare; and really, that's their angle: it adds latency (which has been demonstrated in various commentary on the service) with the goal of modifying content to reduce the number of requests or improve client-side rendering times. It is more of a "content optimization" service than a "content delivery" service. If you want a CDN the tradeoffs (number of edge nodes, latency, cache sizes) are much better with other providers.

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).

http://www.saurik.com/id/14

Good stuff! If you write this sort of article every so often, please set up an RSS or Atom feed.

Here's one security concern - What procedure do you follow when accepting files for inclusion in jsdelivr?

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.

I validate all submitted libraries. I try to do size and md5 validation for everybody. Cases where I do minimum validation is when the author himself submits his library and for trusted people I can skip md5.

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.

To be frank, I'd like to be able to believe and trust you and work myself in a climate where this is generally safe to do. But we're no longer in the early 90's, so we can no longer base technical decisions that concern security on trust in other people's decisions and behavior (esp. when they are not on our payroll). Nor can we trust contracts and legal assessments when even governments are breaking the law.

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)

Add to this privacy concerns. I un-block such 3rd-party CDNs if and only if it breaks specific web sites which I want really want to un-break.

Reply on news.ycombinator.com