Crockford, webhosting, online dating, JSON, alert

December 10, 2009 11:14 am | 23 Comments

This is a fun story that has a security and performance point to it.

Earlier today, Dion Almaer tweeted:

Wow, Doug added an alert() to http://www.json.org/json2.js which just alerted a LOT of people on the Internet. Proving a point on hotlinks?

I was talking to Doug about his keynote at Add-on-Con tomorrow, and asked him what the motivation was for this alert message. It turns out his webhosting service had contacted him about the unusually high amount of traffic on json.org. Doug investigated and discovered that OnlineBootyCall was linking directly to http://json.org/json.js, in spite of this statement in the file:

USE YOUR OWN COPY. IT IS EXTREMELY UNWISE TO LOAD CODE FROM SERVERS YOU DO NOT CONTROL.

Linking directly to http://json.org/json.js is bad. Certainly, it puts a load on Doug’s webhosting company that shouldn’t be there. But more importantly, it exposes the content site to security and performance vulnerabilities. Loading third party scripts into the parent window gives that third party access to cookies and other potentially confidential information in the page. Accessing that script from a third party domain requires an additional DNS lookup (which can be costly). Also, if the script is at the top of the page (which it is in this case) and the third party site is slow or not responding, the entire page is left blank for thirty seconds or more.

It’s best to reduce the number of third party scripts on your site. That was the reason Doug added the alert message to the top of json.js. If you haven’t gone to OnlineBootyCall yet today, here’s what you would’ve seen:

In Doug’s words,

I’m helping onlinebootycall improve its performance.

23 Responses to Crockford, webhosting, online dating, JSON, alert

  1. Hi Steve,

    What is your take on the loading Javascript libraries from Google’s AJAX Libraries API (http://code.google.com/apis/ajaxlibs/) collection?

    I’ve it used more and more by small websites, but have yet to see a truly high traffic website use them on their commercial site.

    Agustin

  2. Hilarious! If you going to be grabbing JS or whatever from another site other than you own make sure that its a CDN (or Google/Yahoo libraries) and not just someones site.

  3. Agustin,

    DomainTools.com is using the google ajax libraries on their whois page, which is getting a very large amount of traffic.

  4. I so am in favor of helping onlinebootycall improve their performance (along with all the other sites who are hotlinking to json.js or json2.js). Way to go, Doug. And thanks for another informative post, Steve. :)

  5. Things like this just crack me up…made for a good laugh earlier today.

  6. @Agustin: If your company has a web farm that is faster and more robust than Google, host the files there. Otherwise, it’s probably better to host them on Google, even at the cost of an extra DNS lookup.

    @Shea: A great combination of funny but relevant. I’d expect no less from Doug.

  7. a whole post just to justify onlinebootycall in your browser history

    :P

  8. This post made this Wookie laugh. Doug solved the leeching problem with style.

    I’m still laughing!

  9. hahaha.. doug rules!

  10. Doug is a super hero.
    I get goose bumps just watching his movies.

  11. You guys are totally right!

    One of our engineers had a major FAIL. We noticed the error today and had to immediately fix it. We too laughed (also shook our heads in utter disapproval) at the fact that warning says “IT IS EXTREMELY UNWISE TO LOAD CODE FROM SERVERS YOU DO NOT CONTROL.”

    Lesson learned.

  12. On the theory, I aggry with Doug, but on practice, it is one of your (Steve Souders) recommandation to load Prototype, YUI, … on Google or Yahoo CDN.

    What must we do ?

  13. “Wow, Doug added an alert() to http://www.json.org/json2.js which just alerted a LOT of people on the Internet”

    http://www.json.org/json2.js

    alert(‘IMPORTANT: Remove this line from json2.js before deployment.’);

    Nice ;)

  14. Good call. But how does one counterbalance this with the desire of users (at least the more on-the-ball ones) to avoid ending up with one copy of jQuery / json2.js / GWT per site using it in their browser caches – or worse, in memory at once?

  15. The “google” question is really simple:

    You ask the owner of the host if its OK to link directly to the script hosted on their server, and you ask yourself if the security implications are acceptable.

    If google says “use us directly” and you trust them, it’s ok.

    If google says “host a copy of the file yourself” or if you don’t trust them, then it’s not ok.

    How complicated can that be?

  16. @gwenhwyfaer Are you serious?

    1. Users, real ones, have no idea what scripts you’re using.

    2. Your browsers cache is designed to cope with different sites using different files. A script is no different to an image.

    3. What evidence do you have that multiple copies of a script file “in memory” is bad?

  17. And how about Google Analytics external file?

  18. hahaha.. doug rules!

  19. @Agustin Colchado Actually, Twitter.com (social networking site ;-) ) loads from googleapis.com. Alexa says it’s 14 worldwide.

  20. Nice!

    (Trying to word this right and not getting it, please read between the lines).

    There is some level of value in referencing files from their “home” servers in that you get any bug fixes/enhancements without having to remember to check for new versions.

    Any notions how to weigh that positive versus the negatives outlined here?

    (BTW, the spam blocker question is: “5 plus twenty-to” instead of twenty-two).

  21. Never mind the BTW above, I see what you’re doing.

  22. @Scott: That’s not a positive, that’s a negative. What happens when that hotlinked script’s bugfix or enhancement breaks your site?

  23. Oh i couldn’t stop laughing. Doug handled the problem very well :).

    Thanks
    Collin paul