Useability 101: Dan Gillmor shouldn't have to play Russian Roulette

It's always comforting to know that another reporter covering the technology sector has run into precisely the same problem I have (and that millions of other people are running into).  It's a ridiculous problem that's easily solvable, and it just takes a handful of vendors to decide to solve it.  In a blog entry posted earlier today, Grassroots Media, Inc. founder Dan Gillmor openly asks if anyone recognizes the warning that his personal firewall is displaying as a result of something -- it's impossible to really tell what -- that his computer is trying to do with the Internet. 

Personal firewalls -- which no one, not even corporate users, should be without (and the one in Microsoft's XP Service Pack 2 is not to be trusted) -- are very "chatty" in this way.  When a personal firewall detects that the computer it's protecting is trying to send or receive something via its network connection that it's never sent or received before, it acts like a bouncer checking someone's ID at the entrance to a bar. It gives the computer's user the option to accept or reject the attempted communication.  Take a closer look at Gillmor's screen shot and you'll see that it gives him the choice to allow or deny and even to supply some parameters (for example, he can allow it forever, or just once).   But much the same way your local night club's bouncer might not be able to make heads or tails of a Japanese driver's license that a tourist may have presented to him at the door, take a closer look at the warning Gillmor must decipher.

In his blog, you can see how Gillmor is making some educated guesses, but he's not sure.  The message is cryptic.  It contains information  that no one but the developer of the applications or Web sites that triggered it, or reknowned PC expert Ed Bott (who solved the riddle for Gillmor) would recognize. Everyday, people like Gillmor are faced with Russian Roulette messages like this.  Only they don't have Ed Bott on call to answer the question.  Instead, let's say an application you're using stops working at precisely the same time that a message like this springs up. If you really want that application to come back to life, you might feel pressured to allow the connection even though you don't have much to go on.  When you think of all the evils on the Net -- particularly the ones that are your personal firewall's very reason for being -- the proverbial bullet is in one of two chambers.  So,  you have that uneasy feeling, you squint, pull the trigger on "allow," and hope all goes well.  And if it doesn't, well, then it's you're own damn fault.  The computer warned you, didn't it? 

Back in the early 80's, when I majored in computer science, I distinctly remember one of my professors telling me that the point of computers was to turn data into information--actionable information. Yet, here we are over 20 years later, and computers are failing miserably at this task, particularly when it comes to something so, well, Russian Roulette-esque.  The bullet just has to be in the wrong chamber. (Or is that the right one?)   

So, what's the solution?  How can we get to the point where Gillmor has quality actionable information, or better yet, he's not even bothered with the warning in the first place?  At the risk of repeating myself (I've already discussed the solution here in 2002, and here again earlier this year), the various anti-malware vendors need to form a consortium, the sole purpose of which is to be a clearinghouse that certifies application and Web site behavior.  So, in Gillmor's case, the question this database could answer is whether an attempt by firefox.bin to connect to the IP address 64.0.96.45.ptr.us.xo.net using TCP port 1935 on the network connection is an expected behavior or not.   Do we know what firefox.bin is?  Presumably, it's Firefox.  But is the one mentioned here the real Firefox, or an imposter?  Where is 64.0.96.45.ptr.us.xo.net? Whom does it belong to? This all could be normal behavior.  But, unless you're the developer, there's no way to tell.

I ran into the same problem with Research In Motion's BlackBerry Desktop client.  In my experience, not only did it want to occassionally check in with BlackBerry's Web site, it very frequently wanted to connect to some server on the corporate network (probably the Exchange Server, but I have no idea).  Imagine if, instead of some cryptic warning, the message said, "Research In Motion's BlackBerry Desktkop Client is attempting to connect to a server with the TCP address xx.yy.zz.aa.  If this is the address of your e-mail server, then this is normal behavior that you should allow."  Or, imagine if, when the BlackBerry Desktop Client did its periodic check in with RIM's servers on the Internet, a similar message was displayed: "Research In Motion's BlackBerry Desktkop Client is attempting to connect to RIM's software update server.  According to Research in Motion, this is normal behavior and should be allowed."  In this latter case, you might even check a preference that causes warnings with a higher probabilty of being normal behavior to never appear in the first place (to default to "Allow").  These messages could even link to Web pages for more information. For example, for Gillmor's problem, if such a feature was in place, it would link to this Web page on the Macromedia Web site. (It's full of the nitty gritty that any geek might really want to see.)

But for this to happen, the database that would be required would not be trivial. There is one such database out there -- UniBlue Systems Process Library -- and it would probably serve as a great head start.  But, it  barely scratches the surface of all software and doesn't even get into Web sites.  So big would this database be (given all the software and Web sites whose normal behavior would have to be tracked) that developing it would be the equivalent of boiling the ocean for any one single security vendor. Together, not only could all the security vendors contribute their intelligence on behavior that's allowable and disallowable to a single database, they could establish a single online service and a protocol so that software and Web site developers could register the normal behavior of their wares with that database.  Why would they contribute? Personal firewalls are often the culprits that break their applications and Web sites.  It's in their best interests to make sure that their wares can actually function when such security measures are in place. (And another reason for a single consortium is to give developers a single registry to interact with instead of one for each vendor.) 

I gave this idea to Zone Labs back in 2002 and the company's executives said they were developing exactly such a database and hinted that it would lead to their competitive advantage.  But for reasons just stated, that's just patently a bad idea.  During a recent meeting with McAfee, Inc. president Gene Hodges, I once again presented the idea and he thought it was a fine idea, agreeing unequivocally that the problem is a real problem and is one that's far too big for any one security vendor to solve.  McAfee offers a personal firewall solution that, like all others, is good on warnings, but short on actionable information.