The Right to Safe Updates

By Peter Coffee  |  Posted 2003-12-08 Print this article Print

Applications must go extra mile to avoid damaging data.

Traveling through Russia last month, a BBC reporter was challenged by police after being observed taking pictures of a river. Asking why he should have sought permission to film at that location, he was told, "There was a bridge nearby." He asked how he could have known. A bridge guard replied, "There used to be a sign there; it just fell off a week ago." Asking why no one had put up a new sign, he was told, "Thats not my job."

Some of the people who maintain software updates must get the same training as those Russian guards. Its not their job to tell you what you need to know; its your job to ask before knowing that the question might arise.

For example, after installing Version 10.3 of Mac OS X, I found that I could no longer use Symantecs Norton Personal Firewall—despite having maintained that product with regular LiveUpdate sessions. A Google search took me to a Symantec Web page that began, "Symantec Macintosh software is not yet fully compatible with Apples new operating system Mac OS X 10.3 ..."

All right, I thought, best to uninstall it, and I ran the uninstall script from the Norton Internet Security CD—only to be told that uninstallation had failed. Back to that Web page. Sure enough, the very last paragraph helpfully warns, "If you want to uninstall a Symantec Macintosh product from Mac OS 10.3, download the Symantec Uninstaller. ..." Oh.

I managed to clean up the mess, but the episode raised several questions. Why wasnt the original uninstaller designed to detect that it was playing on the wrong field? Alternatively, why wasnt an updated uninstaller already on my machine as a result of previous software updates?

My more general point is this: None of us is doing anything on our PCs for the first time, or the last. The products that we buy and the systems that support them need to be designed to work in environments that are subject to change.

My concerns are amplified when Im about to trust a piece of software with the integrity of my entire file system. For example, the most recent version of Symantecs Norton Disk Doctor told me that I had major errors on my OS X disk—but it also thought that I was still running a variant of OS X Version 10.2. At that point, I was about as likely to let Norton Speed Disk optimize my files as I would be to get elective surgery from a doctor who called me "Maam."

An earlier software update incident illustrates another aspect of software design for a changing world. A few years ago, a Network Associates update for McAfee VirusScan damaged master boot records on Windows NT 4.0, resulting in the startup message "Operating system not found." Oops.

Network Associates protested that the conflict involved a version of its product that was, at the time, almost 2 years old, to which I reply that two years is not a long time. When I take a new job, I plan to keep it at least that long. Two-year-old software should not be considered abandonware.

Were moving into environments where code is constantly subject to external changes, whether by update services or because the code itself resides remotely under some other partys control. In these situations, I need to know that software authors have anticipated the possibility that things might change. I want to know that theyve told their code to verify its assumptions before proceeding with potentially dangerous actions.

When software has regular opportunities to phone home for updates, as is the case for almost all software installations today, the mother ship must go beyond merely answering the questions that I happen to ask. I should get warnings when ordinary actions, especially damage-limiting actions such as uninstalling an application, enter unknown territory in which my systems integrity may be at risk.

When the issue is preservation of data, I want to be confident that software knows exactly what its doing or at least that software writers have designed their works to know their limits—and to do, as an absolute minimum, no harm.

Discuss this in the eWEEK forum. Technology Editor Peter Coffees e-mail address is

Peter Coffee is Director of Platform Research at, where he serves as a liaison with the developer community to define the opportunity and clarify developers' technical requirements on the company's evolving Apex Platform. Peter previously spent 18 years with eWEEK (formerly PC Week), the national news magazine of enterprise technology practice, where he reviewed software development tools and methods and wrote regular columns on emerging technologies and professional community issues.Before he began writing full-time in 1989, Peter spent eleven years in technical and management positions at Exxon and The Aerospace Corporation, including management of the latter company's first desktop computing planning team and applied research in applications of artificial intelligence techniques. He holds an engineering degree from MIT and an MBA from Pepperdine University, he has held teaching appointments in computer science, business analytics and information systems management at Pepperdine, UCLA, and Chapman College.

Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel