I'll be out of town for a few days, so I just wanted to wish everyone a Happy Thanksgiving. Hope you enjoy the holiday(s).

Update: 11/26/2006
Please see this post for additional information.

Update: 11/22/2006
A few people have reported an issue with version 1.4.1 that prevents it from extracting any archives. I recommend that you do not upgrade to version 1.4.1 at this time. It may be a few days before I'm able to fix the problem and release a new version, so please continue to use 1.4 or 1.3.1 for now. I'll post another note once I've had a chance to fully investigate.

As hinted at in the 1.4 release post, some bugs and other issues related to internationalization support were found rather quickly. Functionally 1.4 should work fine, but there were some display issues, etc. that needed to be tweaked. So, I'm releasing 1.4.1 as a quick bugfix release to address these problems. I included translation files for Chinese (Simplified), French, and German with this release. Any contributed language files that I receive after this release will be posted to the main Universal Extract page for download, and they'll also be included in future versions.

Universal Extractor Download
Universal Extractor ChangeLog
Universal Extractor Feedback

I just posted Universal Extractor 1.4. The two primary goals of this release are to make it more "portable" (making the history tracking optional, allowing the user to specify where the debugging file is written, etc.) and to add support for internationalization. I also added a few tweaks and fixed a few bugs to try to speed up installer extraction.

Warning: Adding support for internationalization required a substantial number of changes to the code, which may have introduced some new bugs. If 1.3.1 is working fine for you, it may be a good idea to stick with it for a little while until 1.4 is more thoroughly tested. If, however, you are a not a native English speaker, typically run applications from a portable USB drive, or just live for bleeding-edge software, then I do recommend upgrading to 1.4.

Anyone interested in translating UniExtract to another language should follow the instructions in English.ini. If you do this, please send me the completed translation file so I can include it in the next version of UniExtract (as well as probably make it available for download directly from my site). This way everyone can benefit from your work.

The usual links:
Universal Extractor Download
Universal Extractor ChangeLog
Universal Extractor Feedback

Contrary to popular belief, it turns out that I am, in fact, NOT random. Here's the proof:

I know, I'm actually pretty surprised about that myself. :-)

Update
I was bored so I took one more:

So in addition to not being random, I also apparently have confirmation that I have no life whatsoever. Yay!

By the way (since I'm actually posting some news right now), I wanted to mention that I'm currently working on an overhaul of LegRoom.net. This current version has served me well for about 2 years now, but it's starting to show its age.

I hope to have the new site ready sometime within the next month. Porting over all of the content is going to take quite a while, but I've already started making some progress. Once I get farther along (and make a final decision on which CMS I'm going to use), I'll post a preview link for some feedback before it goes live.

In the meantime, if I don't seem to be posting very often, just know that it's because I'm hard at work on LegRoom v3 (and other projects). :-)

Reg Developer has recently published an article exploring the "support vacuum" created when a distribution substantially modifies an application's default configuration in its package system. From the article:

They've configured it right, but Apache ignores it because it needs some extra distro-defined magic to activate the configuration file in question. Now they're banging their head in desperation, and we can't help because we don't know the magic. And we get the blame.

The author uses Apache and Debian/Ubuntu as an example, but this is an issue with most (if not all) distributions. I've had similar problems myself trying to get Apache configured correctly under Gentoo (though the situation has improved substantially in recent versions).

Obviously a distribution will have to make certain modifications to a given application to make it fit in properly with the rest of the system. Sometimes there's just no avoiding it. But the author raises a great point; who will support the applications? If the application developers don't know what changes the distribution made to the application, and package maintainers do not know enough about the application to answer a question, who does it go to?

I hope package maintainers read this article and take it to heart. As I stated above, there will likely always be changes that need to be made here and there to provide a consistent feel across the distribution, but it's important to remember that the more drastically the application is changed, the more difficult it will be for the distribution's own users to get help.

Article link:

http://www.regdeveloper.co.uk/2006/11/04/apache_packages_support_vacuum/

The End User License Agreement (EULA) for the upcoming Windows Vista was made available by Microsoft about a month ago. You can read obtain a PDF copy of the EULA though Microsoft's website.

It turns out that there are several provisions in the EULA that are unusually restrictive, to the point of being draconian (What? Microsoft licensing is restrictive? I'm shocked! Shocked, I say!). Obviously restrictive EULA's are nothing new, but this is a bit much even according to Microsoft standards. Some of the highlights include being limited to one and only one license transfer, being forbidden to run the Home versions in a virtual machine and being forbidden from accessing any DRM content while running under a virtual machine.

There has been quite a few articles written about this in the past couple weeks; however, I think Scott Granneman's article on Security Focus does the best job of detailing the issues. He also includes a lot of links and references to other sources about this.

If you're considering buying/upgrading to Vista when it's released, I strongly recommend reading this article before you do. I'll leave you with a short quote from Granneman's article:

If you thought that the legal troubles the company faced in the late 90s would perhaps mellow it out, you were wrong. Far from it. The draconian limitations I've discussed could only be enacted by a monopoly unafraid of alienating its users, as it feels they have no other alternative.

Full link:

http://www.securityfocus.com/columnists/420

Update - 11/02/2006:
There have been a couple developments since I first published this story. I wanted to put in a quick update to let everyone know what's been happening.

First of all, I'm very pleased to report that this was, in fact, an oversight on the part of the Firefox developers, and they are currently working on a solution to prevent this behavior.

Secondly, it seems that the same issue occurs with Yahoo in addition to Google. This was reported by one of the visitors to this site (thanks, dj), and later confirmed by the German news site Heise Online (here's an English translation of the article).

I'd like to thank the Firefox developers for taking such quick action to fix this issue, as well as those of you that helped raise awareness of it.

----------

I've been testing out the latest release candidate for Firefox 2.0 (which has since been officially released). One of the new features in Firefox 2.0 is ?Previewing and subscribing to Web feeds", which allows users to (according to the release notes):

...decide how to handle Web feeds, either subscribing to them via a Web service or in a standalone RSS reader, or adding them as Live Bookmarks. My Yahoo!, Bloglines and Google Reader come pre-loaded as Web service options, but users can add any Web service that handles RSS feeds.

The nice thing about this feature is the ability to preview feeds. When the user clicks on an RSS or Atom link, Firefox renders the feed in a human-readable format, rather than simply displaying the raw XML as it had in the past*. At the top of the feed page, the user has the choice of subscribing to the feed through different services, as described in the above quote. This is where our story gets interesting.

Before continuing, though, let me provide a brief bit of background on my browsing habits. I always browse the web with Firefox set to prompt me to accept any new cookies. I also use a custom installation package that presets my preferences, so the cookie settings are active on initial load of the browser. This is the reason I noticed this issue to begin with, as I'll explain later.

So, I have Firefox installed and configured, and I begin testing out the new RSS features. The first time I hit a feed (in this case, my own LegRoom.net feed) I was prompted to accept a cookie from fusion.google.com. I didn't think much of it at first and instinctively denied it, but then I noticed the same prompt after a reinstall, and then again on each other feed I visited. This was clearly being triggered by Firefox itself and not by the feed website.

I couldn't find any explanation for this behavior, so at this point I did what any good little geek would do: I fired up a copy of Wireshark (formerly Ethereal) and started sniffing network traffic. After a bit of analysis, I found that immediately after every feed page is loaded, Firefox makes call to Google. Specifically, this is the HTTP data that is exchanged (from Wireshark):

No.  Time      Source   Destination   Protocol  Info
32   3.456833  x.x.x.x  72.14.203.99  HTTP      GET /favicon.ico HTTP/1.1

No.  Time      Source        Destination  Protocol  Info
36   3.587770  72.14.203.99  x.x.x.x      HTTP      HTTP/1.1 302 Found (text/html)

Based on this information, it appears that Firefox is contact Google in order to download the icon used in the Subscription menu select box on the feed preview page. In the process, Google sets a cookie.

Ok, on the surface this sounds innocent enough, but the more I thought about it the more it bothered me. For starters, why would Firefox have to download the favicon Google to begin with? There are three other icons in the same Subscription menu: Live Bookmarks, Bloglines, and My Yahoo. Firefox is obviously able to load local favicons for those services, so why would it possibly need to download Google's favicon from Google's servers? From a technical perspective, it's both wasteful and inefficient.

Second, why is it necessary to include all of the extra data to grab the favicon? Eg, why does Google have to be told which feed I'm browsing (the referer attribute) or what my exact user browser version is (the User-Agent attribute)? The favicon could just as easily be downloaded without providing this information.

Third, why does Google have to set a cookie when providing the favicon? Cookies are used for tracking and session management. In this case, all I'm doing is downloading a graphic. That's it. There is no session management to perform. Again, from a technical perspective this is unnecessary, wasteful, and inefficient.

So at this point, in the best case Google knows your browser version, the page you were visiting, the time you visited, and your IP address for correlation. Now let's examine the cookie. Notice that it's a root domain cookie (.google.com) and not something separate for fusion.google.com. Notice also that it doesn't expire until 2038. Assuming you accept the cookie, which almost everyone will (explained below), Google can also correlate your feed views with all other Google services through the .google.com cookie. I cannot think of any technical need for this, either.

With all of that said, let me stress that I'm not trying to sound any conspiracy theories here. It may very well be some technical limitation or a simple oversight. After all, Google already knows what you search for, what and who you e-mail, who you chat with and what you chat about, who you socialize with, what your social life looks like, what files are stored on your computer, what documents and spreadsheets you work on, what you blog about, what pictures you share, what you shop for, what newsgroups you read, what current events you keep up with, how you run your website, what stocks you monitor, what books you like to read, and, of course, what newsfeeds you read.

Considering all of the above, is there really much benefit to tracking your feed usage through Firefox? To be honest, I just don't know. However, given the fact that Google is very much in the business of collecting data from its users, and that Google has a very well-known relationship with the Mozilla Foundation/Corporation, I feel that this was done intentionally. Furthermore, this tracking is always enabled by default, and there's no way of stopping it.

As I mentioned a couple times above, the only reason I noticed this issue is because I use a customized installer for Firefox that, among other things, begins blocking cookies on initial load. This is important because the default Firefox start page is a Firefox-branded Google search page. So, the first time Firefox is launched it will contact Google and accept Google's cookie (default behavior). Even if the first thing you do after launching Firefox for the first time is to adjust your cookie preferences to prompt you before accepting anything, the Google cookie has already been accepted. Again, I don't think this is part of some conspiracy, but it does compound the issue by making detection of the call to Google's servers that much more difficult.

My biggest question at this point is simply, "Why?". Does anyone know why Firefox does this? Has anyone seen any other reference to this, or acknowledgment of this behavior? I find it very odd that Firefox 2.0 loads the Google favicon, and only the Google favicon, remotely for the Feed Preview page, when the favicons for three other services displayed in the same page are loaded locally. I can think of no technical reason for this, and the only non-technical reason that comes to mind is that Google wants to track your newsfeed habits, and the Firefox made it happen.

What do you think? Am I being overly paranoid here (it's certainly been known to happen)? Feel free to leave your comments below, or just send me an e-mail. (Unfortunately, due to issues with comment spam, I had to disable anonymous comments. You will need to sign in to post a comment.)

-----

*A major issue that I have with RSS Preview is that Firefox will display this preview page even if the webmaster has already written an XSL transform to display the feed in human-readable form. I find this very frustrating, as I spent a lot of time styling the RSS feed for my site, making sure the look and feel matches that of the rest of the site, takes advantage of certain RSS elements available on my site that may not be available on others, etc. However, Firefox 2.0 ignores all of this and instead displays the feed using its own preview style. While this is a great feature for sites that only display raw XML, I strongly feel that Firefox should respect the webmaster's design if he's taken the time to create and specify a particular style/transform for the feed. At the very least there should be an option for users to enable the built-in preview style for all feeds rather than just raw feeds, with it set to only use the preview style for raw feeds by default.

Get it while it's hot! This is a pretty substantial update over the previous version, adding a few oft-requested features and fixing some bugs that had been overlooked in the past. The main highlights are support for variable naming schemes, a new write-mode GUI, improved support for those who only use AutoFLAC for writing, and several bug fixes. Any current AutoFLAC users should upgrade to the new version as soon as possible.

Download links and additional information are available on the AutoFLAC home page. Detailed changes are available in the AutoFLAC ChangeLog.

Wow, I didn't see this one coming (though it's very welcome news):

...future versions of Eudora? will be based upon the same technology platform as the open source Mozilla Thunderbird? email program. Future versions of Eudora will be free and open source, while retaining Eudora's uniquely rich feature set and productivity enhancements. QUALCOMM and Mozilla will each participate in, and continue to foster development communities based around the open source Mozilla project, with a view to enhancing the capabilities and ease of use of both Eudora and Thunderbird.

Qualcomm press release:

http://www.qualcomm.com/press/releases/2006/061011_project_collaboration_mozilla.html

Also worth checking out is the Penelope project page, which is the official Mozilla project that will be dedicated to this effort:

http://wiki.mozilla.org/Penelope