Welcome to Kirsle.net!

It basically relied on the fact that GNOME, KDE, and Xfce treat .desktop files specially, in the way that Windows treats .exe files specially. .desktop is the file extension of Launchers in modern desktop environments, and they used to be launchable without even requiring execute permissions first. With them you could distribute a simple .desktop file via e-mail which downloads and executes malware from the web in one easy "click-and-run" motion from the victim. Read the linked blog post for all the details.

In Ubuntu 8.10 and Fedora 10, as mentioned there, this is how GNOME treated .desktop files; in Fedora 11 (and probably more recent Ubuntu's) things are a little different. Now, .desktop files are inherently untrusted and will prompt the user when they try to execute them. The user can then mark them trusted (which requires them to try and execute them a second time), or just launch them this one time.

When a launcher is untrusted, it displays in Nautilus as a text file. Its icon is a preview of the first couple lines of the text inside the launcher file, instead of the custom icon specified for it, and the .desktop extension is displayed to the user. When marked as trusted they work as before: the .desktop extension is hidden and the launcher gets its custom icon displayed.

Anyway, when you put files into a tarball (e.g. tar -czvf), the files keep their permissions and attributes. Thus, if you put a file with execute permissions into a tarball, it keeps that permission. If extracted on any other unix system in the world, it's extracted with execute permission.

After some poking around, I discovered that the mechanism by which launchers are marked as trusted is simply based on the execute permission. When a program such as wine creates a launcher (for instance, if you just installed a Windows app that puts an icon on your desktop), the launcher is currently untrusted by default, so you'd have e.g. "Mozilla Firefox.desktop" on your desktop; it's not a trusted launcher. When you run it and mark it trusted, all that happens is that GNOME adds execute permissions to the file. You could also run chmod +x "Mozilla Firefox.desktop" in a terminal to do the same thing.

So... for the "virus" in that blog entry to still work on Fedora 11, you'd need one additional step: e-mail them a tarball containing your desktop launcher and have them extract the contents, and then run the launcher. This makes it a little bit less likely that the victim will actually run it, though, especially because if they look inside the tarball first they'll see its real file name (including the .desktop), and GNOME's archive manager won't execute it if they open it directly from inside the tarball; instead they'll get the contents of the file displayed in their text editor.

Here's a random idea that just popped into my head: to help with the security of CGI scripts, certain HTML elements in the forms can be "tagged" in various ways depending on what their function will be once submitted.

So a textarea for leaving a comment can be tagged with name="ta-comment" (ta means textarea), and an input box meant for entering user names only could be tagged with name="user-login", and an input box meant for entering numeric zip codes can be tagged name="num-zipcode".

Then, the CGI script, when it first begins parsing the query string and form parameters, can automatically apply global filters to the inputs based on their tag. This way, every input that might potentially be used to access the filesystem can be filtered so that it doesn't contain any special characters that could introduce a vulnerability in the script, but fields that are meant to be more verbatim (i.e. comment boxes) can be left largely untouched.

# Create a CGI object
my $q = new CGI();

# This will hold your script's parameters
my $args = {};

# Get all the params.
foreach my $what ($q->param) {
    my $is = $q->param($what);

    # Filter the value based on the tag.
    if ($what =~ /^num\-/) {
        # Numbers only!
        $is =~ s/[^0-9]//g;
    }
    elsif ($what =~ /^user\-/) {
        # Usernames are numbers and letters only!
        $is =~ s/[^A-Za-z0-9]//g;
    }
    elsif ($what =~ /^ta\-/) {
        # Textareas turn their line breaks into <br>
        $is =~ s/\n/<br>/g;
        $is =~ s/\x0d//g;
    }
    $args->{$what} = $is;
}

So this way, as you write your front-end HTML code and the back-end Perl, you can tag all the inputs based on how the back-end code will plan on using them once submitted, and the code that collects the parameters when the form is submitted will be sure to format them in a consistent way. So, if your web application consistently doesn't allow quotation marks or HTML code in their text boxes, you can make the CGI automatically remove these things from all your incoming fields, and then just specially tag the ones that you want to be treated differently.

It would protect against accidental oversights by the programmer, and the end user can't do anything about it either. If the text box's name is "num-zipcode", the CGI script will always remove non-numbers when submitted and the user can't do anything about it. If they try to rename it with Firebug to be "text-zipcode" or anything like that, your CGI script won't use their version because it's not named as "num-zipcode."

I think I'll try implementing something like this next time I create a new web application.

I remember that the ability to share USB devices with virtual machines used to be working "out-of-the-box" with VirtualBox and older versions of Fedora, but Fedora 11 complicates things a bit.

By default USB devices in virtual machines don't work; the menu lists all your USB devices as being greyed-out while the machine is running. It comes down to a permissions issue with the user you're logged on as. To fix:

1) Make sure your user belongs to the vboxusers group. Older versions of VirtualBox made this an absolute necessity (virtual machines wouldn't boot otherwise), but VirtualBox 3.0 seems to only create this group but not actually require your user to belong to it for the most part. Update: with current VirtualBox, this is all that's required; USB should be working after you do this and log out and back in. If not, continue reading.

2) Create a mount point directory for usbfs (I did mkdir /usbfs as root).

3) Edit /etc/fstab to add a line that mounts usbfs, giving the vboxusers group write permissions to the mount point. In my case vboxusers had a group ID of 501; check in /etc/group to see what your group's GID is:

# VirtualBox USB support
none  /usbfs  usbfs  rw,devgid=501,devmode=664 0 0

Now, you can either reboot or run mount -a as root (to reload the data from /etc/fstab). If you had to add your user to the vboxusers group because it didn't already belong to the group, you'll need to log out and back in again.

And now your virtual machines can access the USB devices.

I set cuvou.com to redirect all links for regular pages to their counterparts on the new site, and to preserve HTTP referrer information while it's at it (so I can continue to see which Google queries link to my site, for instance). My sites have always been programmed to ignore referring URLs that belong to the same domain (so clicking a link within the site doesn't log the referrer because it would be rather pointless to do so).

But now that the domain has changed, referring URLs from cuvou.com show up in kirsle.net's logs, and it revealed something interesting about the spam bots:

They love my guestbook page. They probably find it via search results for the word "guestbook." Spambots look for guestbooks specifically because they usually tend to contain e-mail addresses, which the bots can add to their list of victims.

My guestbook has no e-mail addresses but instead resembles a blog comment thread... but they don't know that.

Anyway, the interesting thing is, on these requests, the spam bots send the referring URL as being exactly the same as the URL they requested. So their requests look like this:

GET /guestbook.html HTTP/1.1
Host: www.cuvou.com
Referer: http://www.cuvou.com/guestbook.html

The effective result is that cuvou.com's guestbook page is the #1 referring URL (also the #2 and #3 top), because of how popular that page is with the spambots.

Maybe I should set up a spam honeypot on that page and trick them into downloading an infinite number of bogus e-mail addresses that go nowhere to flood their databases with fake e-mails and waste the spammers' time...

There are still some things left to do with it and I need to rewrite a couple of pages, but for the most part it should be fine for now. All the old links on cuvou.com now redirect to kirsle.net; let me know if there are any broken links or anything like that.

I'll post a more thorough blog post about this when I polish up the site a little bit and have time to write about it.

Update: added a traffic-logging plugin, which replaces Cuvou::Traffic on the old site and is better integrated now.

This is a sequel to my rant about GNOME Shell. I decided to back up my claims with an experiment.

Installing gnome-shell in a virtual machine with no 3D hardware acceleration.

Every single desktop environment that exists right now will run just fine in a virtual machine with no 3D hardware acceleration: XFCE 4.6 and older; KDE 4.3 and older; KDE 3.x and older; GNOME 2.26.3 and older; LXDE; and of course all of the desktop-less window managers (IceWM, et cetera).

GNOME 3.0, I claimed, with its GNOME Shell, will be the first desktop environment that will not run unless the user has 3D hardware acceleration, and that there is no fall-back. Here is the proof:

No Guest Additions; No 3D

* Fedora 12 Alpha (11.92 Rawhide)
* VirtualBox 3.0.6 r52128 (2009-09-09)

Let's launch it!

Getting ready to launch GNOME Shell

And... what happens?

Umm...

Hmm...

Let's put on the dumb end user hat and say Joe Average installed Ubuntu 10.10 which might come with GNOME 3.0 and GNOME Shell, he hasn't installed his nvidia drivers yet because they're proprietary and Canonical can't legally include them with Ubuntu, and he logs on and sees THIS. He's lucky that X11 didn't crash entirely and send him back to the login screen, but nonetheless he can't see anything. He can't see Firefox to start browsing the web trying to find a solution to this problem.

Okay, let's move on...

Guest Additions, No 3D

Exactly the same.

I won't post screenshots because they look just like they did the last time. I get a mostly black, unusable desktop.

Of note however is that the terminal printed this upon starting the GNOME Shell:

OpenGL Warning: Failed to connect to host. Make
sure 3D acceleration is enabled for this VM.

Enabling 3D Acceleration

I've personally not used it. But it is known to be buggy; VirtualBox labels it as "experimental"... well, here's why:

Start the shell...

Uh...

This looks promising...

In this experiment, even with 3D acceleration by the virtual machine, GNOME Shell is not usable. Again, though, VirtualBox's 3D acceleration is still in the "experimental" phase. It probably doesn't work a whole lot better with Compiz Fusion, either. Plus my video card might just suck (VirtualBox basically passes the guest's OpenGL calls directly to the host's video card).

But the thing to take away from this is:

• Desktops that work with basic video drivers:
  • GNOME 1.x series
  • GNOME 2.x series
  • Xfce 4.6 and older
  • KDE 3.x series and older
  • KDE 4.x series and older
  • LXDE
  • All window managers
• Desktops that don't work with basic video drivers at all:
  • GNOME 3.0 with GNOME Shell
  • (can you hear the crickets? yes, GNOME 3.0 stands alone, all by itself, in this category. sad. :( )

Now let's see if the GNOME dev team can turn this around in the next year (doubtful; they all come off to me as a bunch of eye-candy-obsessed children who'd rather snazz up the desktop because they think it's "cool" than to worry about things like usability, functionality, or accessibility... and with absolutely no thought given to the user experience, and no usability studies done, etc.).

GNOME Shell for the lose.

The new one seems to be headed in the right direction, though. I named it Siikir, because I plan on adapting it for a multi-user website by the same name after I've first built it so it suits me on my single-user websites.

The main thing that sets it apart from any failure of a CMS I've built in the past is that this one is completely abstract and plugin-oriented... so, the main Perl module that gets loaded doesn't really do anything itself, it only manages the loading and controlling of other plugins... literally everything else (page controllers, user management, sessions, etc.) are all delegated to extra plugin modules.

The general idea is this: if I want to make an ajax front-end that tests whether a username is taken or not, why should the code for that be required to load all the code for pages, photo albums, profiles, blogs, etc.? All it really needs to do is load the one plugin that manages users, and ask it if the user is taken. Simple. So that's what this new CMS structure allows for.

Since I'm liking it so far, I just might release the code after I'm doing working on it. Maybe.

Anyway, it's getting close to completion. Page management, users, profiles, and photo albums are all completed (unlike the photo albums on cuvou.com, each user can make their own collection of photo albums). All that's left is programming a blog back into it, and then I'll be migrating everything on this site over to the new code.

I'll also be changing the domain name; this site is gonna be moving over to kirsle.net with the switch. All the old links to specific files on this site will be redirected to the same files on the new domain, for a while, until Google forgets about the old URLs... then I may use cuvou.com for something else.

Half a year ago the roadmap for GNOME 3.0 was announced, and it involves a new window manager called GNOME Shell. They plan to have GNOME 3.0 ready for public consumption in 2010, around the release of Fedora 13. I tested the GNOME Shell back then and it was awful; since then, it hasn't improved a lot, either. And I'm not optimistic about where it's headed; I think GNOME 3.0 is going to be a terrible, terrible mistake.

If you aren't aware, GNOME is a desktop environment for Unix, and is the default desktop environment for both Fedora and Ubuntu. The other major desktop environments are KDE and Xfce.

GNOME has been said to resemble Windows 98 - true, its default theme is pretty gray and boring, but GNOME is flexible enough that it can be made to look just like OS X or Vista or anything else.

The KDE desktop environment looks an awful lot like Windows as well. KDE jumped from versions 3.x up to 4.0 about a year ago, and KDE 4.0 looks a lot like Windows 7. But on the whole, the desktop still looks and acts the same; KDE's version jump was a natural evolution of its desktop, not a complete change to something completely new and unfamiliar.

GNOME, not wanting to be 1-upped by KDE's version jump, decided they'd bump GNOME 2.x up to version 3.0 -- and entirely redefine the desktop metaphor while they're at it. GNOME 3.0 with its GNOME Shell has almost nothing at all in common with GNOME 2.x.

Here is a relatively recent article about GNOME Shell, so you can take a look.

But that's not why I dislike it. I just thought I'd give some background first. This is why I dislike it:

GNOME Shell requires 3D hardware acceleration. What? Let's compare the current desktop environments: Xfce 4.6 and older, KDE 3.x and older, KDE 4.0, and GNOME 2.x and older... all of these desktops can be run on bare minimal video hardware. You know how Windows Vista, and Windows 7, have "Basic" themes? If you run Vista or 7 on a computer that either doesn't have a kickass video card, or you simply just don't have the drivers installed yet, you get to use the "Windows Basic" theme. Windows has a fall-back to Aero.

But GNOME 3.0 will have NO such fallback. If your video card sucks, or you don't have the drivers, you can't use GNOME 3.0 at all. What will you see? You'll see the X11 server crash and leave you at a text-mode prompt. You will have NO graphical user interface at all; you'll be stuck in text-only mode, because your video card must be kickass for GNOME Shell to load.

Most people have ATI or Nvidia cards, you say? Well, it's well known that ATI and Nvidia have proprietary, closed-source drivers; the companies simply refuse to open up their video drivers as free software. And because Linux is a free and open source operating system released under the GNU General Public License, Linux isn't legally allowed to include ATI or Nvidia drivers "out-of-the-box."

So, when you pop in your Ubuntu or Fedora CD to install it on your computer, the installed operating system can not legally contain Nvidia or ATI drivers. Without the drivers, your video card can't do 3D acceleration. If you were on Windows Vista or 7, you would see the Windows Basic theme; if you're on Linux with GNOME 3.0, you'll see NOTHING! You'll be at a text-mode login prompt, and when you log in, you'll be at a text-mode bash prompt. No graphics, no windows, nothing but text.

This wouldn't be the end of the world for me personally, but then again I know a great deal about Linux. I would be able to install third-party software repositories and install the Nvidia or ATI drivers all at the command line; or at least I would know how to install an alternate desktop environment such as Xfce so that I could get a GUI and then fix the video problem manually. But the average user, or newbie to Linux? They'll be stuck.

I'm curious to see how Canonical (the company behind Ubuntu) is going to deal with this. Are they going to stick it out with GNOME 2.x and ignore GNOME 3.0? I imagine that's quite a likely scenario. Because consider this:

Ubuntu is known as the newbie-friendly Linux distro. It's the easiest one to get set up and running, it's easy to use, and when you log in for the first time it even asks you if you'd like to install some proprietary hardware drivers. Ubuntu can't legally install these automatically but it makes it easy for the user to install them afterward.

What if Ubuntu upgrades to GNOME 3.0, a new user installs it on their computer, and the new user can't even get the desktop to load? They have an ATI card and they don't have the drivers installed, and therefore GNOME 3.0 absolutely will not start because it absolutely requires hardware acceleration. They're a complete newbie to Linux, they know nothing about the command line, but they're stuck at a text-mode prompt. Know what they'll do? They'll switch back to Windows and never be fooled again when somebody wants them to give Linux a try!

Of smaller importance, by reinventing the wheel, the GNOME developers are basically starting over from scratch almost. This means that some of the more complicated problems that the GNOME dev team have tackled in the past may come back. Dual monitor support, for example. The jump to 3.0 is quite likely going to be a large step backwards for the GNOME desktop environment.

I am not a fan of where GNOME is heading. And if the GNOME dev team end up fscking this all up in the end, I'll just be forced to use a different desktop environment. Although, I really don't want to have to resort to that...

I love GNOME 2.x. I can not stand KDE. KDE is just completely annoying to use. Xfce isn't too bad; it shares a lot in common with GNOME (they both use the GTK+ GUI toolkit)... but Xfce feels far behind GNOME 2.x - it feels clunky and old-school, and it lacks certain features that GNOME 2 has, such as integrated dual monitor support; for dual monitors in Xfce you'll have to resort to Nvidia's config tool (if you have an Nvidia card), otherwise you're screwed.

Xfce still has a year to get better, and GNOME 3 still has a year to not completely suck in the end. If GNOME 3 sucks and Xfce is still so clunky, I may even just be forced to abandon the Linux desktop altogether and go back to Windows. :(

Take a lesson from Windows (and literally every single desktop environment in Linux), GNOME 3.0 - don't make 3D acceleration an absolute requirement, and include a fallback version for basic video drivers. Otherwise a really good chunk of your user base will move on to other desktops, or move back to Windows. And if you keep this up, Canonical and Red Hat may even just have to drop you completely as their default desktop environments in their distros, for making life too complicated for the end users.

Late last week I started thinking about how to access a webcam device from within Perl. I have no direct need of such capability at the time being but I wanted to know how to do it in case I wanted to do something in the future involving webcams.

A few years ago when I used mostly Windows I found EZTwain, a DLL library for accessing a webcam in Windows using the TWAIN protocol (which as I understand is obsolete by now). The DLL was a pain in the butt to use and I couldn't get it to work how I wanted it to (it insisted on displaying its own GUI windows instead of allowing my Perl script to directly pull a frame from it without a GUI).

Besides that there's pretty much no libraries Perl has been built to use yet that can access a webcam. So, I started looking into using third-party programs such as ffmpeg and mplayer/mencoder to provide the hardware layer for me so that Perl can get just the jpeg images out and do with them what it needs.

Of these programs I wanted to use ffmpeg the most, because I know for sure there's an ffmpeg.exe for Windows, which might mean that whatever code I come up with might be reasonably portable to Windows as well.

After some searching I found some command-line sorcery for using ffmpeg over SSH to activate the camera on a remote computer and stream the video from it over SSH to the local system, and display it in mplayer:

ssh user@remoteip ffmpeg -b 100K -an -f video4linux2 -s 320x240 -r 10 -i /dev/video0 -b 100K -f ogg - | mplayer - -idle -demuxer ogg

Using the basic ffmpeg command in there, along with some hours of research and poking around, I eventually came up with a command that would activate the webcam and output a ton of jpeg images with consecutive file names, of each frame of video that the camera recorded:

ffmpeg -b 100K -an -f video4linux2 -s 640x480 -r 10 -i /dev/video0 -b 100K -f image2 -vcodec mjpeg test%d.jpg

The mjpeg codec (or "motion jpeg"), in ffmpeg, really means it's a bunch of jpeg images all combined together one after the other (the start of each jpeg image can be seen in hex by looking for the magic number, 0xFFD8). The "image2" format here means that each frame from the mjpeg stream gets written to an individual image file, in the format test%d.jpg where %d is a number that goes up for each image written.

By changing the image2 to image2pipe instead, the output (all the jpeg images in the mjpeg stream) is sent through the program's standard output, so it can be piped into another program, or read from in Perl.

So in Perl I opened a pipe that executes this command and have the script read from it, reading all the jpeg images and then displaying them in a Perl/Tk window as they come in. In effect: a live webcam stream, where Perl is entirely in control of the jpegs as they come in from ffmpeg and can do with them whatever it wants!

I added a button to my GUI for taking a snapshot and saving it to disk (in actuality, as each complete image is read and displayed, it's kept around in memory until the next image is read and displayed... so this button just saves the last full image to disk).

Here's my proof of concept Perl code:

#!/usr/bin/perl -w

# Perl/Tk Webcam Streamer and Snapshot Taker
# Proof of Concept
# Author: Casey Kirsle, http://www.cuvou.com/

use Tk;
use Tk::JPEG;
use MIME::Base64 "encode_base64";

# Some things that might need to be configured.
my $device = shift(@ARGV) || "/dev/video0";
if ($device =~ /^\// && !-e $device) {
    die "Can't see video device: $device";
}

# Tk MainWindow
my $mw = MainWindow->new (
    -title => 'Tk Stream',
);
$mw->protocol (WM_DELETE_WINDOW => \&onExit);

# A label to display the photos.
my $photo = $mw->Label ()->pack();

# A button to capture a photo
my $capture = $mw->Button (
    -text => "Take Picture",
    -command => \&snapshot,
)->pack();

$mw->update();

You can download it here. It should run on any Linux distribution and it depends on having Perl/Tk and ffmpeg installed, and the video4linux2 system (any modern distro will have that).

In the ffmpeg command here you'll see I also piped the output into a quick Perl script that substitutes all the jpeg headers so that they begin with "KIRSLESEP" -- this was to make it easier to split the jpegs up while reading from the stream.

Since this uses ffmpeg and there's an ffmpeg.exe for Windows, this might work on Windows (you'll definitely need to modify the arguments sent to the ffmpeg command, though). I don't currently have access to a Windows machine with a webcam, though, so I can't work on that just yet.

Anyway, here it is: webcam access in Perl!

I, along with pretty much every other savvy computer user, never do the "Recommended" installation of software and always go with the "Custom Installation" route, so that I can opt out of installing unnecessary toolbars and other spyware/adware that comes with free Windows software. But does the Average Joe Windows user know that? Definitely not; the Average Joe just clicks through the install dialogs until the program he wants is installed, not knowing that he also just sold his soul to the devil by installing all manner of malicious spyware on his system.

So, I conducted an experiment.

I installed Windows XP on a virtual machine, and installed only a small selection of software that the average user would likely use, and went with all the "Recommended" installation options for every program installed. Altogether, I only installed 9 programs, and most of those were something everybody can say they've installed: instant messengers.

The Experiment

Memory: 256 MB
HDD Space: 10 GB

I installed a fresh copy of Windows XP, installed the VirtualBox guest additions, and used this as the baseline for a "vanilla" Windows XP installation -- a fresh, clean, pure instance of Windows with nothing really installed on it.

[click for larger screenshot]

In our fresh vanilla Windows XP install, we see the default desktop, the start menu, the Task Manager with few enough tasks in it that we don't even need a scrollbar, and a default Internet Explorer 6 window with MSN as its homepage.

Then, I started installing some software.

Installing Software

Then I installed Yahoo! Messenger 9.0.0.2162 - this installed Yahoo Messenger, put an icon on my desktop, installed the Yahoo! Toolbar, and set my homepage and search engine to Yahoo.

Then, Windows Live Messenger 2009 (Build 14.0.8089.726) - this one didn't install a desktop icon, but it set my homepage in IE back to MSN.com and changed my search engine back to Bing.

These are the three most common instant messengers that most people use. So, I went and installed other essential software:

Sun Java Runtime Environment, JRE 6 version 15. Java also took the liberty of installing the Bing Toolbar in my Internet Explorer.

Then I downloaded WinZip 12.1 Free Edition. Windows XP comes with built-in support for zip files, but Average Joe is bound to come across archives of other types and will be told to get WinZip. WinZip installed for me the Google Toolbar in Internet Explorer.

Then, the Adobe Flash Player 10.0.32.18 - this is, so far, the only piece of software that installs what it says and nothing more. It's also the only thing I've installed in my experiment that installed only what I wanted it to.

Finally, I got a couple extra instant messengers installed: Skype 4.1 and ICQ 6.5 - Skype installed the Google Chrome web browser and ICQ installed the ICQ Toolbar and set my homepage and search engine to ICQ.

At this point, I have only installed 8 programs; 8 programs that Average Joe End User is likely to install. Using the default options on all the installers, my system is now fscked up already. But why stop there? Average Joe also needs an antivirus suite, with all this scare going around about viruses.

So, Average Joe installs AVG Free because Average Joe is a cheapass who can't afford Norton or McAfee. AVG may be well-intentioned, but that didn't stop it from installing the AVG Toolbar "Powered by Yahoo!" into my Internet Explorer as well as changing my search engine to AVG Search.

So, what's the damage? 9 programs, and this is what my system looks like:

[click for larger screenshot]

My Task Manager list has grown exponentially; I have to resize it vertically as tall as it will go, and even then there's still a scrollbar. And do you see the IE window in all that mess? It's completely being murdered under the weight of the 7 different toolbars taking up HALF of the vertical screen real estate.

This is only 9 programs being installed. For a quick list, here they are again:

1. AOL Instant Messenger
2. Yahoo! Messenger
3. Windows Live Messenger
4. Sun Java
5. WinZip
6. Skype
7. Adobe Flash
8. ICQ
9. AVG Free

[click for larger screenshot]

This, THIS is why Windows sucks. All Windows software installs all this crapware along with it, and all this crapware competes with each other (just look how many times my search engine had been changed).

This is the list of toolbars in IE, from top to bottom, which take up 50% of my 1024x768 vertical resolution:

1. (IE Menu Bar)
2. (IE Default Toolbar)
3. (IE Address Bar & Links)
4. AIM Toolbar
5. Yahoo Toolbar
6. Tabbed Browsing Toolbar
7. Google Toolbar
8. Bing Toolbar
9. ICQ Toolbar
10. AVG Toolbar

19 cookies in Internet Explorer. Cookies!!!

The only thing AdAware found were cookies left by ad banners. No adware? No spyware? Are you kidding me!?

So, how do the startup programs look? Well, I'll tell you that rebooting this virtual machine is miserable. With all these programs starting up when the desktop loads, nothing productive can be done for a full 10 minutes. Here's the breakdown:

Startup Items

After this, the startup items were:

• Current User Registry Items
  • AOL Instant Messenger
  • Windows Live Messenger
  • Yahoo Messenger
  • ICQ
  • Skype
  • Google Toolbar Notifier
• System-wide Registry Items
  • AVG Tray
  • Microsoft Default Manager
  • Sun Java Update Scheduler
  • VBoxTray (VirtualBox Guest Additions)
• Start Menu Items
  • WinZip Tray

It should be noted here that free, open source software, almost never comes with crap like this. If you stick to fine programs like Firefox and Pidgin you can install them without worrying about what other crap they'll bring along with them.

I hate Windows.