ILOVEYOU hit on Thursday. By Tuesday the cleanup is mostly complete. Estimates of the damage range from $5.5 billion (industry analysts) to $15 billion (overhyped press coverage); the real number is somewhere between, and is large.
The early-note post focused on what defenders could do now. This post is about what the platform — Microsoft, principally — would need to do to make this category of worm structurally impossible. None of it is going to happen quickly. Worth writing down anyway, both as a benchmark and as a reminder of what the real fix would look like.
What the platform should do, structurally
Five things, in roughly increasing order of how hard they are organisationally.
1. Show the full filename
Windows Explorer hides "known" file extensions by default. A file named LOVE-LETTER-FOR-YOU.TXT.vbs displays as LOVE-LETTER-FOR-YOU.TXT. The user sees what looks like a text file, double-clicks it, runs a VBScript.
This is the enabling deception of ILOVEYOU and the entire double-extension worm family. Without it, a user staring at a .vbs would at least have a chance of recognising executable code.
The fix is one default change in the OS. Microsoft has known about this for years. The reason for not changing the default is, on the available evidence, that it makes the OS look slightly more cluttered to non-technical users — every filename now has an extension visible. The trade-off favours user-friendliness over security.
The fix should ship in the next major Windows release. It will not.
2. Treat email attachments as untrusted
Windows currently treats files as files. An .exe is an .exe whether it came from a CD-ROM, a network share, or an email attachment. The OS has no concept of provenance in the trust sense.
A proper fix would track where files come from. A file received as an email attachment, or downloaded from the internet, would be marked as untrusted. Untrusted files would, at minimum, prompt the user before executing — with the prompt explaining the source. Untrusted scripts would refuse to run unless explicitly approved.
The technical foundation for this exists in the NTFS filesystem (alternate data streams). The user-experience layer does not use it. Building the integration is real work but is feasible.
The fix is non-trivial. It might appear in the next major Windows release as an opt-in feature. It will probably not be the default for several more years.
3. Restrict scripting hosts by default
Windows Scripting Host — the system component that runs .vbs files — was added to Windows in 1996 and enabled by default. It runs scripts with the full privileges of the calling user. There is, in current Windows, no permission system between "the user can do X" and "the script can do X".
The right architecture is for scripts to run in a restricted environment by default — limited filesystem access, limited network access, no automatic email-sending capability. Specific privileges granted on request, with explicit user approval.
This is a meaningful platform-level change. It would break some legitimate scripts. The cost-benefit favours the change but the friction is real.
4. Remove the address-book MAPI access by default
The specific mechanism ILOVEYOU and Melissa use to propagate is to access the user's Outlook address book and send mail to it programmatically. The MAPI interface allows any process running with the user's credentials to do this.
The right architecture is for unattended programmatic use of MAPI to require explicit authorisation. The first time a script tries to send mail, the user gets prompted: "This program is trying to send email. Allow once? Allow always? Refuse?". The choice is remembered.
Legitimate scripts that need to send mail (small number) get authorisation once and continue working. Worms (large number) get refused, every time, by users who have not been trained to click yes to everything.
This is a UX change to the platform. It would mildly inconvenience some legitimate users. It would dramatically reduce the propagation rate of mass-mailing worms.
5. Default-strip executable attachments at the mail client
Outlook should refuse, by default, to display or save attachments with executable extensions. The user who genuinely needs to receive an executable from a colleague gets a warning and an explicit override. The user who receives a worm-laden mail from someone they know gets the executable filtered out before they can double-click it.
The technical change is small. The categorisation list — what counts as executable — is a known list, maintained as part of the security update. The user-experience cost is the friction for legitimate exchanges of executables, which is a small population.
This is the change I expect Microsoft to actually make, sooner rather than later, because the pressure is now sufficient. I would expect the next Outlook update to ship with default attachment blocking for at least the most dangerous extensions.
Why none of these will happen quickly
A few structural reasons.
Backwards compatibility. Each of the changes breaks something. The platform has hundreds of millions of users; even small fractions of broken use cases are large absolute numbers. Microsoft is averse to changes that break user expectations.
Default-experience purity. The Windows team has historically valued a smooth out-of-box experience. Anything that adds friction — extension warnings, script-permission prompts, attachment blocking — degrades the visible quality of the product to a non-technical reviewer.
Existing relationships with corporate customers. Many large organisations rely on macros and scripts in their internal workflows. Restricting these by default would generate substantial customer pushback. The corporate customer base has, historically, been the louder voice in Microsoft's product decisions.
Organisational structure. The Office team and the Windows team are separate organisations. Solutions that span the two boundaries — say, fixing the Outlook address-book exposure and restricting WSH simultaneously — require cross-organisational coordination that is structurally hard.
None of these are insurmountable. All of them slow change.
The realistic path forward
My expectation, written down so I can score it later:
By 2001: Outlook will ship with default executable-attachment blocking, with a list of about 50 dangerous extensions. This will dramatically reduce simple worm-by-attachment propagation. New worms will use slightly different vectors.
By 2002: Windows Scripting Host will be more restricted by default, possibly disabled in fresh installs. Scripts that need to run will need explicit enabling.
By 2003: Some kind of file-provenance tracking will appear in NTFS or the Windows shell, marking attachments and downloads as such. Initially as opt-in, eventually as default.
By 2005: Mail clients will treat attachments as untrusted by default and require explicit user action to extract or execute. The user experience will adapt.
This is the slow timescale of platform change. The threat actors will adapt faster. Whatever defences are deployed by 2002 will face the worms designed against those defences in 2002.
What this means for operators
The practical position, at least until the platform changes ship:
Strip executable attachments at the relay, regardless of inconvenience. The trade-off has shifted decisively toward stripping.
Move mail-handling away from Outlook where possible. Linux desktops with Mozilla or Pine are not vulnerable to this category. The substitution is operationally non-trivial but the security benefit is substantial.
For Windows users that must use Outlook, apply the security templates Microsoft has been quietly publishing, with macros disabled, attachment blocking enabled, scripting restricted. The templates are awkward to deploy but reduce the attack surface meaningfully.
Plan for the next variant. ILOVEYOU is the second mass-mailing worm category change in 18 months. There will be a third. The timing is uncertain; the arrival is not.
A harder lesson, which I am still chewing on: the platform's security posture is, in some real sense, the operator's threat model. We can mitigate around it. We cannot fix it. The structural improvement requires the platform vendor to act, and they will act on their own timeline. Until they do, the operator's job is to apply the defences that can be applied and to advocate for the structural changes that should be.
This is uncomfortable. It is also, on the available evidence, the truth.