Hacker News Reader

Comment by dedward | Hacker News Reader

Always seemed to be to be a bad practice from a security point of view - you are putting the security of your site in the hands of whoever is hosting the .js

This also applies when .js is dynamically included as a type of API call to embed widgets and whatnot - but in those cases there's a necessary reason - it's the only practical way - but for a simple .js, you should be managing your own .js library and publishing on your own (including all the speedup tricks you know you should be doing)

View on HN

> Always seemed to be to be a bad practice from a security point of view

This is why I can't understand people's recommendation to use Google's or Microsoft's CDN. Even if you assume they're not going to be malicious, you have to trust that they're secure. Not to mention that the CDN owner can derive accurate traffic stats from the number of requests for the JavaScript.

Why would I be less sure that they're secure than my own personal hosting?

No reason you would be. But you can be sure that your personal hosting is more secure than (your personal hosting ∪ Google). In the latter case if either breaks you're screwed.

You know the components of, and the capacity to upgrade, your own stack. With hotlinking, you (and consequently your users/customers) have an external dependency to a mysterious system with who-knows-what going on.

As long as the CDN is configured to transmit its files with a far-future expires header (which Google and Microsoft's CDNs are), the CDN owner can't accurately track usage at all.

In a perfect world, the CDN would only handle one HTTP request per user per expires period (+1 year on Google and Microsoft's jQuery CDN). In reality, the file will be pushed out of or cleared from caches for various reasons, but they still persist long enough to make tracking end-usage of the CDN meaningless.

Performance. Many of your visitors will already have it in their cache.

My concern has always been the one-day-in-a-thousand when the CDN will be down and so my sites won't work. When my sites go down it doesn't matter as the entire package stops working, but I'd hate myself ten times more if things stopped working due to an admittedly extremely rare CDN failure.

That said, I'm open to the idea that I'm being extremely foolish about this ;)

Most users will have the javascript in their cache anyway, so they won't even be hitting the CDN. Also, why not check to see if the object exists before doing anything else?

    <script id="jquery" src="http://code.google.com/jquery.js"></script>
    <script>
    if (jQuery == undefined) {
        document.querySelector("#jquery").src = 'Backup CDN';
    }
    </script>

That should work, in theory, if not then just remove script#jquery, create a new one and append to the document before executing any script(s).

It's at times like this that I feel really stupid ;) Thanks, you can guess what I'll be changing on my sites the minute I sobered up, err, sometime in the next couple of days ;)

iirc changing the src attribute directly does not resend the request (in at least some browsers). you need to create a new node.

Stolen from the html5 boilerplate

    <!-- Grab Google CDN's jQuery. fall back to local if necessary -->
    <script src="//ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.js"></script>
    <script>!window.jQuery && document.write(unescape('%3Cscript src="js/libs/jquery-1.4.2.js"%3E%3C/script%3E'))</script>

Superb, thank you! I'm more feeling significantly more enlightened :-D

Plenty of people use Google Analytics, which, of course, gives Google just as much access.

I trust Google and Microsoft enough for the benefits I get in return (faster loading clients). Sure they can screw me over but not too badly. Worth the risk for some applications.

Reply on news.ycombinator.com