Hacker News Reader

Comment by niyazpk | Hacker News Reader

Why?

Because every page in the app is bound to carry the jQ dep, and you can just as easily provide your own static file hosting for jQ. It seems like a pointless complication to the security model of an app, to take its core Javascript framework library and host it offsite.

You really think your home-rolled static file store will be more resistant to compromise than Google?

This question is nonsensical. If you can't host a static file you are screwed no matter what. We can argue about how much of a risk Google CDN is (I don't think it's much of one), but it's not zero.

"Home rolled static file store"? Sheesh.

No offense, but from my perspective you're getting a little rude here without really explaining the situation.

So far I grasped from you that external static files compromise the security model so much it's worth the time and effort to keep up to date with them locally and be okay if the page load times suffer (they do especially with minimalist sites.)

I understand the risk that Google CDN might be hacked and turned into a data mining monster, but it would, at the same time, infect so many important and popular sites on the whole web, I can't even imagine my sites being targeted.

    but it would, at the same time, infect so many important and popular sites on the whole web, I can't even imagine my sites being targeted.

Maybe, or maybe it's exploited to target only your site by detecting referrers and only serving your site malicious javascript. Thomas is correct in arguing to host your own.

This implies I can do it better than Google or any other big-name-company CDN I happen to trust.

I don't know about you or Thomas, but this isn't true for me.

You ignored the point I'm making. You don't have a choice but to do "static file hosting" securely.

Lots of sites use Google's CDN so it's very likely the file is already in your user's cache. That seems like a nice little speed bonus if the only trade off is the theoretical risk that Google's CDN might be more easily hacked than your own server.

As an aside, I notice on my site there are a few precent of visitors with security settings on their browser that prevent loading from Google's CDN (actually, there's usually an internet security product of some sort interfering). So you're going to have to provide a fallback to a file on your own server anyway.

Of course! Your whole app is hosted on your server, you're already hosting a bazillion images and other files, including scripts and CSS - if your server is compromised it won't matter much whether your jquery.js is safe or not. Also, aside from security concerns, you're adding an unnecessary single point of failure to your project.

Sure, CDNs are advertised as super reliable and stable and whatnot, but all services go down once in a while. As with every monoculture, there will be large scale outages. It's something developers would be better off acknowledging and planning for upfront instead of having a heart attack whenever a service goes down "unexpectedly".

There is a way to fall back to locally hosted version in case the primary one goes down. Still not convinved I should give up on the speed bonus a precached asset gives me.

Thomas wasn't really discussing about this in regards to the external CDN going down he was discussing it in regards to the CDN being a large point of attack with little benefit to your speed increase.

Look at it this way: if google's jquery is attacked and becomes compromised you and everyone else who uses it has become compromised because you were relying on third party security.

Next if you use jquery from google's cdn for the reason of they can do file security better than you you are already fucked because if someone is targeting your specific jquery hosted on your server chances are you are compromised in other ways.

If you want to use it for the precaching you can but I don't think precaching the 100kb jquery is really going to give you that much benefit in the long run, especially if your website is an application or something along those lines.

The worst offenders here are those who host their jQuery and offer it to others on a domain that is also being used to host other web applications.

For eg. company xyz.com is a hosting company, but it also offers jQuery and other javascript at cdn.xyz.com.

A client of the company at client.xyz.com is setting a cookie for its users but sets it as xyz.com. Now everybody else that is using cdn.xyz.com will also see those cookies.

One example of this is the cloudflare CDN[1]. All of their clients and all of their hosted javascript is on the same domain. Test it out by checking the cookies your browser sends along[2], I see random Techcrunch cookies (they used cloudflare on a site)

[1] http://www.cdnjs.com/

[2] http://cdnjs.cloudflare.com/ajax/libs/backbone.js/0.5.3/back...

Reply on news.ycombinator.com