Anyway, if you have the slightest interest in either of those things, you should go check out my coworker’s post titled “Google Maps + IE8 Beta 1 = Epic Fail.”

Other individuals / companies have certainly written about this before, but I haven’t seen anything on it in a while now and I figured it’d be nice to have a refresher. Without further ado, following are some practices that we follow at Diverse Solutions that, as a website visitor, I wish more companies would follow.

1. Shrink Your Code: This really seems like common sense to me, but far too many people aren’t even aware of the tools available to help developers in this area or just don’t care enough about the benefits. JS compressors, in case you’re not aware, do anything from strip unnecessary whitespace and comments to actually changing the names of private variables to smaller names to save space. We use Dojo ShrinkSafe, but I’ve heard JSMin does a pretty good job too, and I know that there are a number of others that will probably fit the bill as well. They are pretty easy to use if you take the time to set them up, and the benefits are definitely worth it. In most of our apps, we’ve created batch files that run ShrinkSafe on most JS files in the deploy directory so that we don’t have to really mess with it after we’ve set it up.
2. Compress Your Code: Use server-side compression if the client truly supports decompression. GZIP can be your friend, but it can also be your enemy if the client doesn’t support it properly but says it does (looking at you, IE6). Some claim it’s not that big of a deal and that the problem isn’t very widespread, but we’ve had our fair share of clients who had problems with us compressing JavaScript. The problem is primarily related to this bug, but there are other things that can cause problems with compressed content as well. Basically, we’ve found that you’re best bet is just to conditionally serve compressed JS to browsers that say they support it except for anything below IE6 SP2. You can do this with server-side code if you intercept your requests to JS files. We run IIS 6 and use ZipEnable so that we don’t have to write anything extra to take care of this.
3. Don’t Include Libraries You Don’t Use: This, again, seems like common sense. I’ve happened upon way too many sites that include Prototype or Dojo or something just because they likely think that they are going to use it, but they never end up using a single part of it. My advice is to only include the library after you’ve learned how to use it, not before.
4. Use Versioning: This is something we fairly recently started doing, and we don’t know why we never did it before. Versioning is especially important because of this bug in IE6. Basically, versioning involves appending a querystring to the end of every script’s tag src attribute. The querystring doesn’t / shouldn’t change the file being requested, but because you can change the querystring when you deploy, the browser will re-request the file with the next request and get the new version of your script. It can definitely be a pain to manually manage changing the querystring at the end of all of your JS files, so we have the value of the querystring variable set as a server side variable that we can just change in one place to make everyone’s browser reload everything. Sure it reloads some files unnecessarily, but like everything else regarding JS optimization, it’s a balance between extra work and better practices.
5. Minimize Client Requests: Yahoo! pre-compiles some of their YUI libraries so that developers can just include one or two files in their apps and get the functionality they need, and we do the same thing with most of our libraries / applications. Separating thousands of lines of JS into separate files can really help with organizational purposes, but serving those multiple files to the client can really be a drag to visitors, especially in light in of studies like these. What we’ve done to help fix this is create a quick server-side app that reads an XML config file to determine which JS files to include in the single request. We can then ask for something like /CompressedScripts/Prototype.js to get our Prototype.js file, the Event.onDOMReady file, Justin Palmer’s awesome EventSelectors extension, something we wrote for generating SOAP requests, and Sylvain Zimmer’s impressive $$ addon. That’s five potential requests that we’ve merged into one request, saving an incredible amount of unnecessary requests over the lifetime of our app. I should note that we don’t use versioning (point 4) on our libraries just because it would probably degrade performance most of the time since the libraries rarely change.

Anyway, that should get you started. Of course you can do even further, but like I said, it’s definitely a balance between extra work on your end and unnecessary bandwidth / slow-ish performance on the client end.

As a developer myself though, I have a curiousity that exceeds most others’ desires to know how these applications were build. I want to know what is underneath the hood and how good the developers themselves are. In the past, it was nearly impossible for outsiders like me to look at the underbellies of these applications to gauge the skills of those to made them. However, with the past few years, application code in the form of JavaScript has been pushed to the client an amazing rate and new tools have surfaced that make it easier to dig into this code.

This code is where the crux of my issues with a number of companies lies. You’d think that with the massive amounts of money that these “Web 2.0″ companies have been raising lately that someone there would ensure that the code that is pushed to the client is both secure and efficient. In my opinion, security hasn’t changed all that much. All JavaScript / AJAX forces a developer to do is just take more time to ensure that the way he would have done things otherwise was the right way to do things. AJAX just reduces some of the guesswork that a hacker / cracker / whatever would have had to put in to break the app the way they wany. On the other hand, the efficiency of that code is something new that web developers must learn and get used to.

My entire family is a family of engineers. We’re obsessed with efficiency, optimizations, and often perfection. I might actually be the worst of them all, as I’m always trying to make things better — just ask my wife, as it drives her crazy. Therefore, I’m going to attempt to focus my quest to make things better on a number of very popular websites that I have already singled out. You’ll see this come to fruition in a number of posts of posts over the next few weeks. After that, I’m not sure which direction I’ll end up taking with this blog.

However before I can tell other companies what they are doing wrong and how I think they can do things better, I’ll have to share my own practices that I use on a daily basis to deliver what I feel is the best code possible with the constraint of time over my head. You’ll find all of this in my next post.

I’m currently the webmaster of transportdesigns.com, the website for my dad’s business of the same name. I used / am using WebHost4Life to host it just because I didn’t really know of any good Windows web hosts (Windows needed because of an ASP.NET app I am making) and because it was reasonably priced. Also, because of all the crap littered around Google pertaining to web hosting reviews, it’s nearly impossible to find out whether or not a company is good just by doing a search on it.

Anyway, things were okay for a while. I wasn’t too impressed with their backend, but as long as it was stable, cheap, and had the functionality I was looking for, I was okay. Late November rolls around, and I get an IM from my dad asking him what the black box was doing on the middle of his page over top of the content. Hmm, I don’t remember putting a black box on top of the content, so lets go check it out.

Here’s what I find: http://transportdesigns.com/index2.html. Uh, whaaa? There is a black box in the center of the page. I look closer, and discover that that sweet box is actually an IFRAME tag linking to http://81.95.146.133/sutra/in.cgi?17. I definitely don’t remember putting that there. I investigate it a bit more, and put everything I found into an urgent support request to WebHost4Life. Following is my request in it’s entirity.

It seems that someone has hacked into the web server that houses my website and has changed the index.html page. I renamed the page to index2.html and fixed the original for the time being so that you may do an investigation into this issue. Before you write me off as an ignorant web hosting newbie who doesn’t understand the implications or definition of hacking, please read my description of the problem below.

My specific problem is that the former index.html page (again, now index2.html) has maliciously had an iframe inserted below the html tag that links to the following url: http://81.95.146.133/sutra/in.cgi?17. The URL then issues a 302 redirect to http://81.95.146.133/sp/new/index.php, which contains just a single script tag with what looks like compressed JavaScript on it (so that I cannot tell what the JavaScript actually does).

I have searched Google for this IP, and found the following site detailing the malicious nature of the activity surrounding the IP: http://national.auscert.org.au/render.html?it=6537&cid=2998.

I keep the FTP and control panel passwords for my web host encrypted on my hard drive with a stronger cipher than is necessary [I use KeePass]. No one else knows any of my passwords nor my decryption key to open the password file on my hard drive. I know that I would never deface my own home page, so I am convinced that this occurred due to an internal security problem on your end.

I am absolutely livid that this has happened to my home page while being hosted at your company and consider it to be a massive security issue (which is why I marked the request with such a high priority). Please investigate this matter as soon as possible and let me know of the outcome so that I can take appropriate actions.

Four hours later, I get a response from “Peter C.”

We are now running a fix to remove all the IFRAM tags you stated above in all of your pages. Could you please remove all the IFRAM tags in your pages if you see any? I would suggest you not to open those inflected pages in IE before they are fixed. If you found it happen again, please open a new ticket and report the issue. Thank you for your cooperations!

So my friend “Peter” tells me that they are “running a fix” to remove all the “IFRAM” tags in all of my pages. Based on what he said, I have to assume that this is a widespread hack on their servers and that they wrote a script to fix everyones’ pages who may have been affected. He also says that I shouldn’t open the “inflected pages in IE before they are fixed.” Thanks Peter. I’ll just call up all of my dad’s potential website visitors and let them know to use Firefox for a while. I write back.

As far as I was aware, the IFRAME was only added to the index.html page. However, your response _DOES NOT_ address my issue. Was the server hacked?? If so, why was I not informed earlier? What assurances do I have that this will not happen again. Finally, what kind of compensation do you plan on giving me for this absolutely massive security issue and the poor way your company has handled it by not notifying me after the likely hack??

I am still very upset over this whole issue and will spread the word about the infiltration into your network unless I get some good answers as soon as possible.

I get a response from “Candy.”

Could you please let us know when specifically you have discovered this issue so that we could have a closer look on? Thanks.

Wouldn’t it make sense that, with such a critical issue, I didn’t just wait for two weeks before letting them know? Cmon now. I respond.

The issue was discovered within about 10 minutes of my support request post. Therefore, I was notified of the problem at about 11/20/2006 2:30 PM.

“Rick” responds now.

We did not receive any reports from other customers about the same issue. Also, we also double checked our security settings and everything is good. Have you made sure you do not grant write permission to any users on your files? Hackers are likely to insert codes to your script if you grant write permission to the files.

What?! At the moment, it was a purely HTML site you bozos! I don’t think any l33t haxors inserted any “codes to my script” through my HTML files that only had the default read permissions. My response:

There are absolutely no dynamic scripts on that site that are anywhere public. In addition, the one ASPX page that I _am_ developing that sits on that server does not use any sort of file write mechanisms. I don’t claim that my code is flawless in any way, but I also am certain that there is no way that the code I have written so far on that site could be used to change files within that directory. In addition, I have not granted write permissions to any files whatsoever on this server. You will be able to see that yourself if you investigate further. Please look into the issue further and get back to me as soon as possible. … I am still not satisfied at all with the answers I have received.

“Rick” responds again.

Are there any special permission setting on your root folder? I can reset to default permission for you. Also, we suggest you to change all your password, say ftp, control panel to prevent hacking access.

Like I told him before, I have not changed the default permissions. This is getting really stupid. I respond, again.

There are no special permissions set on my root folder. You can check it if you’d like. The only users who have write access to any of my folders are the SYSTEM user and Administrator. None of the users I have control over have ever had write access to any folders within my directory, including the root directory. Therefore, I am lead to believe that the attack came from somewhere outside of my control. I will reset my password(s), but I still would like to know if my password was leaked from your system or the server was attacked or another user on the server was able to use a script to write to other directories or any number of the other possibilities. I have refrained from publicizing this attack on my blog until now, but this whole thing “blame the problem on a rogue user script or bad file permissions or user error thing” is becoming quite tiring. I am willing to answer questions regarding my script or my file permissions, but I can assure you again that my script never used any of the System.IO (file access) libraries, that my file permissions were never changed, and that my FTP password was definitely not leaked anywhere.

In addition, I was told in my first response that a “fix” had been written that was removing all of the IFRAME tags from my pages. If no other customers reported any incident, and since the problem was only on my main page, why was the script even written and what did it actually change on my site?

“William” responds with “we will have senior staff to reply to your question shortly.” You know, as an aside, I really wish that their support staff could speak / write better English. Anyway, along comes Mark to finish out the support request.

Steve, up to now, we did not have another customer on the same machine reported they are hacked. So we believe it should not be a hacking to our global setting but only your account.

Of course, this case is being recorded. We have checked through the entire server and it seems fine. The two possible method the hacker change your site is through change your webpage or modify it by FTP access.

Right now we checked your file permission settings and it is solid. However you may need to change your FTP password regalarly as well.

So that’s it. In my opinion, I received absolutely terrible customer service from five different people across six different responses, and not one of them offered me a half-decent explanation other than the flimsy idea about that hacked FTP account. Lame. Also, they completely avoided my question about this mysterious “fix” that was running through all of my 10 or so HTML pages to remove the IFRAME tag (of which only index.html was affected by the way). If it really was only me that was affected, why did they write that script. Did they even write it? Did they lie to me? Why wasn’t it removed from the index2.html page as it exists right now?

I’m still pretty upset about the whole issue and would switch web hosting companies away from them in a second if I got a referral on a better one. Not that it would have soothed my anger against them at all, but I can’t believe they didn’t even offer me a month of free service to keep my mouth shut. Can’t anyone provide even a tenth of what Dreamhost offers us in the Linux hosting world?

What do you think? Hacked? Are there even any other viable possibilities?

I’m cooking up some pretty good posts on a myriad of different topics, so hopefully I’ll have something worthwhile up here real soon. Until then, this little post will just have to fill the void.