InformationWeek

The first step is to remember that "function" is indeed the culprit. Data that arrives in the body of, or as an attachment to, an E-mail is inert--it can't do much more than display a nasty message, and data can be deleted at any time.

But when function is allowed in--as a macro attachment that starts executing as soon as the document is opened, or as a program file that you click on--there's a potential for real trouble. Before you know it, this function can worm its way through your computing environment. The recent ILOVEYOU virus was a fragment of Visual Basic script that ruined files, installed additional destructive function, and re-sent itself to other computers.

One protection is to erect a firewall that keeps all unvetted function out of your system. But assuming that you still want to receive executable code by E-mail, it would seem logical to devise some kind of "lead box" that would let you peek inside a mystery message without exposing the vitals of your system.

We haven't studied E-mail architecture extensively, but it seems to us that a potential solution lies at hand. Billions of lines of executable function have been downloaded to millions of computers without any mischief. These are Java applets, sent to browsers via the Web and executed there--perhaps drawing a little squiggle or depositing major subsystems. Thanks to Java's distinctive virtual machinery, this function poses no danger.

The Java virtual machine is software that resides on a browser and functions as a mini-CPU. It sets up a walled-off, self-contained execution environment, called a sandbox, where all Java code received via applet runs. Applets executing within the sandbox have no file access, no "property" access, and network access so limited that applets can only reach out to the servers from which they came.

Why not extend this architecture to E-mail clients, equipping them with their own virtual machine and sandbox? This environment would have to be specially designed for E-mail attachments (we could call them "attachlets"), which would presumably be heavier-duty than most applets and might need access to certain resources outside the sandbox. Here we could use the configuration properties built into Java 2, which let you make the sandbox somewhat permeable when certain conditions are met.

The attachlet sandbox could be made very smart about evaluating the function it holds and deciding whether to let it out. Each E-mail vendor would come up with its own set of sandbox policies (which each user could configure further), but here are some ideas:

• The sandbox would be able to command any attachlet wanting outside access to reveal ahead of time what it intends to do, and warn the user if these plans fall into a preset "risky" category: "This program will delete all your .jpg files and those of everyone you know--OK?"
• The sandbox might impose an embargo on access to your E-mail address book. It might prevent the insertion of new code into executable system files. The sandbox could be set to reject anything without a digital signature, protecting against spoofed sender names. And while it couldn't analyze non-Java function, it could at least alert you to the fact that an "unevaluatable" E-mail has arrived and ask whether you want to take the risk.
• An alternative is to do in hardware what the Java virtual machine simulates with software. The computers of the future could be built with an auxiliary processor whose sole job would be to execute functions received from outside. This scheme could handle any E-mail attachment, not only Java. There would be some extra expense, but who wouldn't pay a little more for a virus-proof computer?