In the weeks before Fall 2003 when the students arrived the W32.Blaster virus was bring down networks all over the world. Our university instituted a policy to have all internet services disabled and only enable them one by one after the students machine was certified clean and was patched to protect against it. Our network stayed up. We started to notice very strange things happening with students’ computers that turned out to be SpyWare/MalWare infections.

Over the summer prior to Fall 2004 I developed a CD which walked the student through the long and arduous task of preparing Windows to run safely on our network. It downloaded windows patches, Symantec Anti-Virus, Anti-Spyware and directed them to turn on a firewall. Some flaws quickly bubbled to the surface. For the most part it worked well for everyone however in certain situations the computer became infected in minutes which is far less time than it takes to install Windows patches. We were still very busy but overall it greatly reduced our workload and we considered this a resounding success. I also attended the ResNet conference at Princeton and was blown away by how helpful it was. Every school seemed to be dealing with the same issues as us.

During the next year we learned more and more about SpyWare/MalWare which was becoming the issue with computers. When a particularly damaged computer was discovered I was called in as the last resort to formatting. In most cases I was successful thanks to the now famous netsh int ip reset. During this period my job shifted toward tools and Linux. I wrote Perl scripts and used various tools to help with the administration of the network and the discovery of problem systems. The summer brought yet another ResNet conference which I attended at Georgia Tech and learned quite a bit.

A new technique was implemented for the students moving in during the summer term. We had them enable the Windows XP firewall and install Symantec Anti-Virus after which time we would enable them and they could update windows freely without fear of infection. It was a great success and cut our issues down to a handful. We have since streamlined the technique with even greater success and for the first time had idle staff during the move in period.

My job working with Linux came to a halt since it was evident that we didn’t need to develop any heavy-handed student computer management software. At this point I started to develop websites (yet another shift). The first project was to replace the Off-Campus Housing Listing Service website with a new friendlier interface. I had very little experience with web programming and so created the first website using ASP which was the language in which the old site was written. After it was finished I looked at ASP.Net for the next project and decided to switch for the increased programming library. It is nearly a year later and I have developed many applications and continue to improve our web presence. Currently I am looking into Web 2.0 techniques for use on internal applications. I imagine this is what I will do for the rest of my time here at UW, web applications are the medium of the future.

Here is the info for those that are interested.

Starting: April 28 2006 11:00 PM EST (April 29 2006 3:00 AM UTC)
Ending: April 30 2006 11:00 PM EST (May 1 2006 3:00 AM UTC)

GameDev story, Ludum Dare main site

Let me know if you sign up :o)

I am working on a personal project called bookkeeper which is a database for the books that I have read and what I thought of them. It started a ways back as an excel spreadsheet then evolved into an access database and then into a web application in php/mysql. My intention is to eventually make it so others can also use bookkeeper, but that isn’t going to be for a while.

Password storage was the first thing to tackle and turned out to be pretty simple. Storing passwords that have passed through the SHA-1 algorithm is the standard practice but has certain security issues. An improvement suggested it to create a unique random string per user to add to the password before hashing it. This reduces the ability to perform dictionary attacks on the hashed passwords. The random unique string is called a salt value and is stored alongside the final hashed password in the database for later comparison, I use an MD5 hash of a number from rand() cut down to twenty characters.

The next issue was session handling and security for the rest of the pages protected by the login page. The standard seems to be to use session_start() which by default generates a cookie containing a session id which you can check at the start of each script page and redirect to the login. So if you are like me you immediately think, ‘what about malicious users?’. Session hijacking is the default scenario seems very easy to me so some precautions are a good idea.

1. Make sure to call session_regenerate_id() after every user login so that the old session id is discarded. This will prevent a user from changing the session id cookie to look at another user’s information after logging in normally.
2. Don’t trust that the session id stored in the cookie is valid. After the user login store the new session id in the database to be checked at the top of every page before the rest of the session information is trusted. This will prevent a user from changing their session id to become another user while logged in.

That is all I have so far. I would really love to hear how others do this stuff and if there are some issues I haven’t mentioned here that are important to remember. Please send in all your paranoid security methods.

As a side note I am very curious about what web platform and server languages Google uses to write all its applications such as search, gmail, google maps, etc. Currently I assume it is CGI with the back end written in with a C like language or something home-brewed.

Please let me know what you think of the stuff so I can make it more useful. Also I would like to know if there are any topics that you would like covered or covered in more detail. My plan is to integrate my graphics blog posts and examples into this section so they are easier to navigate.

For now enjoy :o)

Here are the finer points:

1. Completely JavaScript/CSS/XHTML built so no server side stuff is required.
2. No tables at all in the calendar control so the design is more flexible and easier to style across different browsers. I used horizontal rollover lists for the day rows instead and they work very well. This means there is no need for extra JavaScript to light up the days on mouse over just use a:hover.
3. Very simple to include in a website. Just need an element with a .value property, a div container and to include the .css and .js files.

Demonstration

Grab the files you need here (right click -> save as…).

1. datepicker.js
2. datepicker.css
3. index.html

I tried to keep everything as simple as possible so you might need to expand it to fit your needs. Please let me know if there are any issues with any browsers you test on.

ASP.Net Calendar Issues:

1. Clicking on the calendar for changing months or selecting days requires a post back and requires extra Page_Load code to pass by any processing code that shouldn’t be run before the form is filled out.
2. Placing an asp:Calendar control in your form puts a table into the page source.
3. The calendar control doesn’t popup by itself. It requires a bit of JavaScript finagling and a surrounding div. Working JavaScript into an ASP.Net application isn’t the easiest thing to do.

There are probably a few more, but I stopped working with the calendar control and started to build my own simple JavaScript/CSS one with much better flexibility.

It is certainly possible to overdo it when using a technology such as this and so I will give, as an example, an application with a good need for it. Generally the new information that you are going to load into the current webpage will be collected from a database. The primary page that the client will load is a simple query with many records but not much detail. The point of this is to reduce the load on the database server and improve the responsiveness of the page. Now the detailed information for each record can be loaded on demand based on the user’s actions, such as clicking a certain record.

You might be thinking: “What is the point of that? Just have the click go to another page with the rest of the information or use a popup.” Both of these options are possible of course and have been used many times successfully in the past. What we want to do is set our site apart from the rest, not blend in. By using XMLHTTPRequest and some simple JavaScript we can generate a new fly-out section accessible via some visual cue beside each record. These fly-outs start empty and are filled by JavaScript when the data is returned. Done correctly the user will never notice that the information is being loaded on the fly and will be impressed by the dynamic nature of your site. The bonus to us is that the amount of bandwidth generated by our web application is reduced.

Google has an amazing suite of very novel applications that use XMLHTTPRequest to make the user experience that much more impressive: Google Suggest, Google Maps and GMail (if you don’t have a GMail account let me know and I can invite you). I am now a firm believer in more functional web applications as I believe that web based (platform independent) applications are a much better idea requiring less work for system administrators.

At this point I am still on the fence about using JavaScript so extensively. I have always been concerned with using it too much. It can easily be turned off or not supported consistently on the client side which would break the functionality of the site without a lot of extra programming to cover all the possibilities. My main concern however is that the JavaScript can be modified by the user using things like GreaseMonkey. After you send a website off to the user you have to check everything on its return. Its been proven many times over that you can’t trust JavaScript form validation and have to rely on server side validation when the page comes back. Since AJAX uses JavaScript heavily it is very tempting to trust the user and I believe some designers with fall into this old problem with this “new” technology.

Time will tell if I am right about the security issues but for those out there with the know how and the loose morals, get ready for an explosion of sites that are vulnerable to well known attacks.

EDIT: I am definatly leaning toward the pro side after reading this article and checking out some of the applications (especially kiko).

I have an ATI Mobility 9600 and after fixing a few bugs all of a sudden my research was not running at interactive frame rates any longer. The frame time was several seconds for a page of 100 different shaders where before it was several milliseconds. So I ran out and bought an X850 Pro on sale at Future Shop and threw together a computer with it inside. I re-ran my experiment with the EXACT same results. I had a suspicion already that noise was the root problem so I disabled it and everything ran lightning fast.

After a bit of research (thanks to the GameDev.net forums and google) I learned that ATIs implementation is terrible and the NVidia’s always returns Zero. Both are very bad options as they both say on the box they support OpenGL 2.0. Neither company documents the issue officially. Mark Kilgard of NVidia does maintain a document on NVidia’s OpenGL support which mentions the problem. ATI did not respond to inquiry on the subject.

The solution that I was pointed to by the fine people on the GameDev.net forums was to use SimpleX Noise. This version of noise was created by Ken Perlin (of Perlin Noise fame) to combat known issues with his original algorithm. It has lower computational complexity, less artifacts and is easy to implement in hardware. For more information see this article which has source code.

I’ll try to get some feedback up on SimpleX noise once I progress further.

I tried using global constants, local constants and regular variables but they all have the same result, slooooowwwness.

On a side note:
Parkour is an awsome sport full of awsomeness. You should try it. It is sometimes called free-running, here are some links. Have fun and be safe.

Urban Free Flow
Clip from Banlieue 13
Levity Group Parkour
Parkour Toronto
Parkour.NET
David Belle (Inventor of Parkour, 100% french)
Sébastien Foucan (Co-Inventor of Parkour)