TransparentMaker

Sko commented on the last post inquiring about a program I had a long time ago which allowed you to make various windows on your desktop transparent. It was an old-school Windows 2000 program I wrote to try out the fancy new WS_EX_LAYERED styles in Win2K:

You could drag the cursor over a target window and adjust its transparency or make it 'always-on-top':

It's extremely simple but it was pretty cool back in the day. I just tried it out and it still seems to work for the most part, but not as well on newer versions of Windows like Vista, due to the increased security that prevents processes from messing with each other.

An interesting unintended use of the program was that it could be used to discover saved passwords in '******' textboxes, since it displayed the result of WM_GETTEXT as you dragged the cursor over various HWNDs. Fortunately they seem to have fixed that vulnerability in XP+.

Anyway, here's a link to download it:

TransparentMaker.zip

Windows Updated

For the final project in a class I am taking we had to build a web-based disk storage system with a REST XML API, basically like Amazon S3 but at much smaller scale. The assignment was pretty cool because it was very open-ended: our servers just had to register their URLs with the professor's server and allow him to store data blocks. How we actually did it (OS, language, etc) was completely up to us.

I decided to just run my server on a computer at home, which is what most people did. I figured it would work out fine. My biggest worry was that Comcast would block a port or go down and screw me over. Fortunately that didn't happen, but there were other problems.

For about two weeks my server ran perfectly with 100% uptime, but the professor only started monitoring uptime and availability this Tuesday. Of course, on Tuesday afternoon there was a power outage at home, and my computer didn't turn back on until I got home from work and found it. I have my main computer hooked up to a UPS so it didn't go down, but the other computer was running in a closet with no UPS. Lesson learned: always have a battery backup when homework points are at stake. Also, set all computers to reboot themselves automatically after a power loss.

After I booted it back up I figured it was OK and went to bed. Of course, this happened to be the second Tuesday of the month, so Windows Update downloaded a bunch of patches overnight and rebooted, taking out the server. My process failed to start on reboot, so I had another outage all night. Normally I always set updates to "notify only" and never "automatic", but in this one case I left it on automatic, figuring that it wouldn't matter too much since it was a closet-computer that I wouldn't even log into regularly. Lesson learned: never ever ever leave the updates on automatic, they'll always find a way to screw you at the wrong time. Also, test to make sure the service comes back up properly after a reboot.

Larger-scale, I guess I learned about the importance of having geographically distributed datacenters and automatic failover, but that wasn't really a practical option in this case.

Fortunately most of the other students in the class also suffered outages as well (see graph above), so I don't think my grade will be impacted too much.

CampusChat

Today while going through some old files I found an old program I wrote back in college for a Microsoft-sponsored programming contest. Microsoft was doing a big marketing push for the newly-released .NET Framework and C#, so they sponsored programming contests at various universities to promote it (hook 'em while they're young? cough). I ended up winning an original Xbox, which was also new and cool at the time. Somewhat ironically, there was a guy from Sun Microsystems at the contest who saw my program and got me a part time job there working on Solaris.

The point of the contest was to write an application that would be useful for the university, so I decided to write an instant-messaging system called CampusChat. At the time the university had no global IM system that students could use to communicate with TAs and professors, or find and collaborate with other students. My ultimate goal would have been to create a grand, unified online environment like Project Athena at MIT, but I only had a couple of months so I went with IM.

It also allowed me to finally 'correct' all of the horrible (perceived) flaws in the corporate IM systems of the day (namely AIM, MSN and Yahoo). These flaws were:

• The IM servers were centralized and under the control of one corporation; people could not run their own servers.
• The IM client software contained advertisements that had to be hacked out of the executables.
• IM sessions were not encrypted on the wire, so your dorm-neighbors and ISPs could read all the messages (this has been mostly corrected these days, thankfully).
• IM sessions were not encrypted end-to-end, so the IM provider could read all your messages (this is still not fixed today..).
• Trust and authentication were ad-hoc, with no method to determine who you were actually talking to.
• There was no way to tell if the person you were talking to had actually received your recent IMs or had become disconnected (extremely annoying back in the dial-up days).
• You didn't know if the other person was in the middle of typing a message to you or not.
• Other users would often select horrible, ugly fonts that you could not override.
• The customizability of your own font and UI themes were very limited.
• There was no plugin architecture that you could use build apps on top of the IM system's authentication and communication layers.

The (arguably) largest flaw of the corporate IM systems was that they weren't interoperable with each other at the time, and by creating my own IM system I was admittedly making that problem even worse (open protocols like Jabber and SIP did not really exist yet).

I based CampusChat around Kerberos 5, which is a distributed authentication system that can be used for secure client-to-client communication using strong encryption. All of the IT infrastructure at the University of Colorado was based on Kerberos 5, so every student and faculty member already had Kerberos IDs, which were their usernames and passwords. It was also integrated into Windows 2000+, so if you were logged into a computer with your university username, CampusChat automatically grabbed your credentials from your login session and you didn't have to type in your password again.

Kerberos allowed for the encryption and mutual authentication of individual IM sessions between users, so that you knew exactly who you were talking to, and nobody along the wire (even the IM server itself) could read the communications. I realized later that since Kerberos is based on having a trusted third party generate the symmetric keys (rather than using public-key methods), its entire security rests with the "trusted third party" – in this case the university IT department, which was arguably nothing of the sort (as far as us Computer Science students were concerned). A malicious Kerberos server could have ruined the entire security scheme.

Once you logged into a CampusChat server, the main 'Buddy List' window looked like one of these (all screenshots are using the 'chess' theme):

The screen on the left is of a server in "community mode", where users can see all of the other people who are logged into the same server and the public chat rooms that are available. This mode was designed for individual classes or departments – a professor could set up a server for his/her students to use for collaboration, allowing students to find each other and their TAs during 'virtual office hours'. This mode is contrasted with 'classic mode', which is on the right, and behaves just like AIM or MSN, where you have lists of 'buddies' that you maintain, and you can only see the online status of the people you have explicitly added. This mode was designed more for university-wide servers which everyone could log into at once. The controls on the bottom allow you to add buddies and create public or private chat rooms. The blue slider at the bottom of the window allowed you to adjust the transparency of the window and set it to be "always on top".

IM windows look like this:

The first thing they do is initialize a secure encrypted connection with the other user. At the bottom of the window the status bar lets you know that all of your IMs have been received by the other party (or it lists the number of outstanding messages for which an ACK has not been received). It also tells you if the other person is currently typing, and has the transparency-slider control. The "Direct TCP connection" button allows you to establish a direct connection to the other user, in order to cut out the IM server from the conversation (for speed, as well as to prevent malicious servers from logging the timing and frequency of your messages).

The Text Settings dialog allows you complete control over all of your text. You can use any CSS styles you want on your text, and you are also given the ability to override your conversation partner's CSS text styles if you don't like them. For example, if you were to use the CSS string "text-align: right; background-image: url(http://www.google.com/images/logo.gif);", you would get this:

CampusChat also supports Unicode (natively, since it is written in C# and Managed C++), which allows you to converse in any language (AIM was infamous at the time for not supporting Unicode):

Multi-user chat windows are pretty similar to IM windows, though users have less control over various settings:

CampusChat supported an extensive plugin API, which you could use to modify the base client software and build your own applications on top of the secure connection. It just required implementing a specific C# interface and plopping your DLL into a specific folder. Complete .NET objects could be easily sent between clients using simple function calls (they were serialized to binary form, compressed, encrypted, and sent out automatically).

To keep things simple, I implemented a lot of CampusChat functionality as plugins, such as file-transfer, away-messages, directory lookups, speech recognition, and text-to-speech. The away-message functionality was particularly cool because you could write your own away-message provider that allowed all kinds of fancy logic about which specific people to send the messages to, different messages for different people, and so on. To demonstrate the flexibility and power of the API I also created a full-featured chess game as a plugin (only requiring a couple hundred lines of code):

Alas, in the end CampusChat died a death of neglect after the programming contest and was never widely adopted at the university. It still works great, but you can only use it if you have a valid Kerberos 5 account on some domain, which I no longer do. I've uploaded the ZIP file here for posterity:

• Zip file with CampusChat source code & binaries (2.18 MB).