Melissa shouldn't surprise us
By Peter Coffee
March 29, 1999
PC Week Online

Microsoft Office is a new breed of enterprise platform, enabling a high degree of inter-application communication (IAC) and permitting extensive customization. These are strengths in the hands of responsible users and disciplined programmers, but they become grave risks on public networks exchanging content among untrusted sources.

The Melissa virus demonstrates Office's risks, and serves as a warning to enterprise IT architects and users that there's no such thing as a convenience without a cost.

Microsoft's Bill Gates told us what he had in mind, eleven years ago, in a Byte magazine article entitled "Beyond Macro Programming." In his own words, recalling that article in a March 1998 retrospective, he "called for the creation of object models that would enable developers to control all the elements of an application, providing full application programmability."

Driven by Gates's personal vision, Microsoft took us there -- by way of the bumpy road of DDE, OLE, OLE 2.0, and finally COM/DCOM plus Visual Basic for Applications.

Beginning with the success of the spreadsheet, which turned static tables of numbers into dynamic mathematical models, Gates and his hand-picked team of technology Officionados have added the same kind of dynamic character to word processing, presentation graphics, and databases.

The result, apart from high costs of adopting and discarding several IAC models along the way, has been a collection of breakthrough power tools that are notably lacking in elementary safety features. Microsoft gave us remotely controllable applications before it gave us protection of our personal systems, just as the consumer electronics industry gave us cordless phones before it solved the problem of electronic eavesdropping; just as the automobile industry invented the automatic transmission, to help us accelerate more quickly, before it offered us antilock brakes.

Office dissolves the boundary between operating system and application, and even between application and data: an Office document can retrieve data from remote sources, manipulate data with external code, and even manipulate other applications with no intentional action by a reader (who may have no idea that these actions are taking place).

Are we there yet?
Microsoft's Gates knows what he wants: like many dwellers on technology's leading edge, he wants computers to let him express new ideas and communicate them to others. Microsoft's employees, by and large, want what Bill wants.

But there is a fundamental problem with this happy picture of talented people with vision, commitment, and resources.

It's all right to have geniuses build systems for use by idiots, but the path from laboratory to marketplace needs to go through the proving ground of prudent engineering.

Consider the first elevator: the person who first thought of throwing a rope over a branch, and pulling down to raise something up, was probably a genius -- at least, relative to those around him. But the first person who tried to duplicate the idea may well have wound up with a fractured skull when a rope slipped or broke. That's the difference between invention and design.

Today, the essential concept of an elevator is almost buried -- desirably so -- in safety mechanisms. Genius may innovate, but engineering assimilates. Today, most of the intellectual capital invested in the idea of "an elevator" is spent on keeping the user from getting hurt. And elevators only do one thing.

Microsoft Windows and Microsoft Office do many things, a growing number of things, a bewildering variety of things. At the same time that Microsoft is modifying the elevator, so to speak, to move sideways and to fly, they are trying (often halfheartedly) to add safety on instead of designing it in. The result is never as good as it needs to be.

Windows begins with the model of a single user on a single, personally controlled machine, and never recovers from the resulting assumption that no piece of code would be on a machine if the user didn't want it to be there.

Old school strengths
Perhaps it takes a Melissa virus to make users realize that old-school IT management practice was prudent, and not just paranoid; in particular, to realize that breaking down the barrier between programs and data may not be an unmixed blessing.

There was, not that long ago, an almost sacred distinction between "production code" and every other part of a company's information base. Production code was documented, validated, subject to configuration management, and constrained with regard to the resources that it could use.

Data, if corrupted, could misinform the user -- but it could not alter the function of the system. Fresh data could always solve the problem.

With Visual Basic for Applications as a universal macro language, Microsoft has made the system self-modifiable. This is a risky proposition, even in the hands of skilled programmers (famous for party tricks like redefining "4" to equal "5" in the self-modifiable Forth language).

Where do we go from here?
There are at least two ways to retain the strengths of a networked enterprise, without suffering from Parkinson's Disease of (what Microsoft calls) our Digital Nervous System.

First, there are intrinsically safe active-content models like those of the Java Virtual Machine, with its facilities for strictly limiting the privileges of any piece of code. Depending on a Java applet's origin, or on the storage directory in use, or even on the day of the week or the phase of the Moon, a JVM environment can decide whether an applet will be allowed to perform such actions as opening files or making network connections.

To be sure, imperfect implementation of Java's specified functions has left occasional security loopholes, but these can be fixed -- unlike the fundamental security weakness of ActiveX or COM/DCOM, inherent in Microsoft's distributed object model.

Second, there are rich data models that do not rely on executable content. Dynamic HTML gives the active role to the host (the browser) rather than the guest (the COM-enabled Web page); XML invests data with meaning, but does not seize control of the client machine.

Melissa does nothing new. The risk of the macro virus has long been known. Melissa, like an especially successful virus in nature, merely appears to be an especially effective example of its kind.

What makes Melissa notable is its arrival on the scene at the same time as genuine remedies, such as those described above, and at a time when many enterprise IT architects are especially open to new ideas about who will define their platforms' directions.

Weary of delays in the next generation of Windows NT, and of the continuing high cost of administering complex Windows clients, IT managers may well decide that this is the time to find a better way.

For magazine subscription savings, risk-free trial issues, newsletters, and more, click here!