It's Official: I'm NOT Random

Submitted by jbreland on Sun, 11/05/2006 - 21:49

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!

New Website in Progress

Submitted by jbreland on Sun, 11/05/2006 - 03:04

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). :-)

The Linux Distribution Support Vacuum

Submitted by jbreland on Sun, 11/05/2006 - 02:58

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/

Windows Vista Licensing

Submitted by jbreland on Fri, 10/27/2006 - 14:19

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

Is Firefox/Google Spying on Your News Feeds? (Update)

Submitted by jbreland on Wed, 10/25/2006 - 11:52

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
Hypertext Transfer Protocol
   GET /favicon.ico HTTP/1.1\r\n
      Request Method: GET
      Request URI: /favicon.ico
      Request Version: HTTP/1.1
   Host: fusion.google.com\r\n
   User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0\r\n
   Accept: image/png,*/*;q=0.5\r\n
   Accept-Language: en-us,en;q=0.5\r\n
   Accept-Encoding: gzip,deflate\r\n
   Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\n
   Keep-Alive: 300\r\n
   Connection: keep-alive\r\n
   Referer: http://www.legroom.net/backend.php\r\n

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)
Hypertext Transfer Protocol
   HTTP/1.1 302 Found\r\n
      Request Version: HTTP/1.1
      Response Code: 302
   Location: http://www.google.com/favicon.ico\r\n
   Set-Cookie: PREF=ID=7e3b29ec472e1e47:TM=1161728606:LM=1161728606:S=4O7AZZG6VrvWd_V5; expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.com\r\n
   Content-Type: text/html\r\n
   Server: igfe\r\n
   Transfer-Encoding: chunked\r\n
   Content-Encoding: gzip\r\n
   Date: Tue, 24 Oct 2006 22:23:26 GMT\r\n
   Cache-Control: private, x-gzip-ok=""\r\n
   \r\n
   HTTP chunked response
      Data chunk (197 octets)
         Chunk size: 197 octets
         Data (197 bytes)
         Chunk boundary
      Data chunk (10 octets)
         Chunk size: 10 octets
         Data (10 bytes)
         Chunk boundary
   Content-encoded entity body (gzip): 207 bytes -> 230 bytes
Line-based text data: text/html
   <HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
   <TITLE>302 Moved</TITLE></HEAD><BODY>
   <H1>302 Moved</H1>
   The document has moved
   <A HREF="http://www.google.com/favicon.ico">here</A>.
   </BODY></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.

AutoFLAC version 1.2 Released

Submitted by jbreland on Mon, 10/16/2006 - 01:09

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.

Future versions of Eudora to be based on Thunderbird?

Submitted by jbreland on Wed, 10/11/2006 - 16:13

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

Man demands that book about book-burning be banned -- during Banned Books Week

Submitted by jbreland on Fri, 10/06/2006 - 10:34

Via Boing Boing:

"Last week, a 15-year-old girl at Caney Creek High School (near Houston) complained to her father [Alton Verm] about "bad language" in Ray Bradbury's classic SF novel Fahrenheit 451. Dad complained to the district and pushed for the book -- which tells the story of a man in a futuristic, totalitarian society whose job is to burn unapproved literature -- to be removed from the curriculum. As the icing on the cake, his request came during the last week of September, which just happens to be the American Library Association's Banned Books Week."

Best line in the article: "It's just all kinds of filth," said Alton Verm, adding that he had not read 'Fahrenheit 451'.

And as a bonus (also found on Boing Boing), here's some helpful family planning advice.

Google Code Search

Submitted by jbreland on Thu, 10/05/2006 - 14:00

Google recently introduced a new search service specifically for source code. Google Code Search "helps you find function definitions and sample code by giving you one place to search publicly accessible source code hosted on the Internet." I played with it very briefly, and it definitely seems to have potential. A FAQ is also provided to help you get started.

CRN published an article covering Google Code Search. It's worth a quick read if you ever have a need for this sort of thing (which, admittedly, most folks do not).

Full links:
Google Code Search - http://google.com/codesearch
CRN article - http://www.crn.com/sections/breakingnews/breakingnews.jhtml?articleId=193104796