This one could be controversial ;-)
In a recent comment, Edd James (note to Edd: that link gives a 403) asks why Outlook and Excel "need this ability to run scripts/macros[?]"
First I want to clear up a common misconception about Outlook: Despite what the endless ill-informed posters on Slashdot might claim, no recent version of Outlook (or recent update to an old version of Outlook) is designed to run code out of e-mail messages in the default configuration. Every once in a while someone finds a bug in the IE rendering engine or in Outlook that enables such execution, and that bug is fixed. Customers who want "dynamic" e-mails can still enable the feature through the Outlook security settings, but it is not the default and is not at all recommended.
But moving on, let's turn the question around: why shouldn't Outlook have a rich object model? I challenge you to give me a sound answer to that question based on security concerns (I can understand why you might not want the feature for "code bloat" reasons, etc.)
The obvious answer is that having an object model in Outlook makes all those mass-mailing viruses possible. Apparently anyone who uses that argument hasn't heard of the recent viruses going around; that latest "virus technology" doesn't rely on Outlook to do its dirty work. It scans files on your hard-disc to scavenge e-mail addresses, and then it uses a built-in SMTP mailer to send out the mails. If you are running Lotus Notes or Pine or Eudora or Mozilla Mail or any other e-mail client and you execute a MyDoom-like virus program, you are in trouble. (At this point, someone may point out that their e-mail program of choice is not susceptible to the virus de jour because the virus only understands the Outlook address book file format. True, but that has nothing to do with whether or not Outlook exposes an object model, and everything to do with the size of the installed user base).
The next answer is that having an object model in Outlook makes all those mass-mailing viruses easier to write. It is too easy for a "script kiddie" to cobble together some VBScript code and take over the world, so the argument goes. But the term "script kiddie" doesn't necessarily literally refer to "kids" writing "scripts." It refers to relatively unskilled people (of all ages) downloading sophisticated attack tools (written by the "real hackers") and then using them in some possibly-automated fashion. I doubt the average "script kiddie" has enough m4d c0ding 5ki11z to even write "Hello World" in VBScript, let alone craft something sophisticated like MyDoom. What the kiddies can do is surf around on #hacker IRC channels, download pre-canned exploit code from hackers, double-click on the icon on their desktop, and then brag to all their other 1337 friends. Basically, the really bad people (the criminals) who write real viruses don't need the Outlook OM to do their dirty work; sure if it is there they might choose use it, but they don't need it.
Of course the other point is that having an OM makes it easy for legitimate developers to write applications that better meet their customers' needs, and that is A Good Thing. We don't want to make it arbitrarily hard for "the good guys" to build solutions using our technologies, and in the end it won't really buy us anything since the bad guys are more determined than the good guys and so they will persevere with writing their malware whether we "help" them or not.
In fact, by making it hard for ISVs to write against the Outlook OM, you can argue that the world has gotten worse because customers now typically install 3rd party applications such as ClickYes or Redemption to re-enable access to Outlook... and those programs may have security bugs of their own!
The next answer (and a slightly better one) is that many people don't need the object model, so in order to reduce the attack surface of Outlook it should not be installed. The same argument has been used for WSH (Windows Script Host) as well, and you could make it for all sorts of other features, too; installing anything on your system (even security software) increases the attack surface of your system in one way or another. But the fact is though that these kinds of features don't actually present a very compelling "attack surface" as we usually define it. The person making this particular argument is probably missing the point. Once the malicious code is running on your system, it's game over man, GAME OVER!
I think this calls for an analogy :-)
One day a burglar breaks into your house. You surprise them in the kitchen, so they grab a sharp knife out of the drawer and stab you with it before running away. In an attempt to prevent this from happening in the future, you banish all knives from your house when you return from hospital. Sure, it might be hard to cut your steak from now on, but that's the price you pay for security. (Thanks to Randy for pointing out that "cheese" was not a good choice of words here for an American audience... :-) )
A few weeks later, the burglar breaks into your house a second time, and you surprise them in the kitchen again. This time they grab a big saucepan from the drawer and hit you over the head with it before running away. After returning from the hospital, you remove all saucepans and frying pans from your kitchen to improve the security of your house. No cheese and no fried food might be good for your waistline, after all!
A week or two goes by, and the burglar strikes again. This time you catch them in the bedroom, and bereft of cooking implements they pick up a shoe that is lying on the floor and throw it at you. One trip to the hospital later, you have no choice but to ban shoes from your house as well. Hmmm, this could make going out for a walk a bit tricky, but hey, you have to protect yourself, right?
What's the point of this analogy? Well, you have failed to perform a root cause analysis of the problem. The problem isn't that you have knives or saucepans or shoes in your house; it's that the burglar keeps getting inside! If only you'd invested in a good-quality front-door lock (and possibly a guard dog or an alarm) none of this would have happened. And to appease the "attack surface reduction" argument, removing knives and saucepans isn't a very effective technique because the burglar will just start packing their own weapons or perhaps they'll come in at night when you're fast asleep. A good attack surface reduction technique in this scenario would be to permanently seal the back door (so there's only one main entrance to the house) and to place bars on all the windows (so there's less room to crawl through).
In the same way, removing WSH or Outlook or any other piece of "end user" code on Windows doesn't really help with attack surface reduction, and won't improve the real security of your machine one bit (it simply makes you less vulnerable to the more "popular" attacks, which is cold comfort indeed). Now don't get me wrong -- attack surface reduction is a great thing and we should be doing more of it. But a better example of attack surface reduction is the disabling of unneeded services, or the blocking of dangerous attachments in e-mail messages (the thing most responsible for the drop in e-mail viruses, until ZIP files became the infection vector), because both of these represent possible attack vectors for malicious code. Once malicious FullTrust (native) code is running on your system, it doesn't need any help from installed applications. As an extreme example, imagine that Outlook completely dropped its object model in the next version, and imagine further that nobody else in the world knew how to write a program to send e-mail. Mass-mailing viruses would still be possible; they'd simply bundle an old copy of Outlook '97 into their virus payload and use that to do their dirty work!
This is where threat modelling comes into play. If you yourself are writing some software and are worried about exposing features to COM or .NET clients because of the security implications, then think of it this way. If your threat is:
· User downloads malicious full-trust code that uses your application's OM to do harm
Then you also have the threats:
· User downloads malicious full-trust code that sends windows messages to your application to do harm
· User downloads malicious full-trust code that patches the binary (or in-memory image) of your application to expose an OM and then uses it to do harm
· User downloads malicious full-trust code that duplicates the functionality of your application to do harm
What is the root cause here? It is User downloads malicious full-trust code and that is the thing that you (or rather we :-) ) should be trying to address with things like firewalls, proxies, virus scanners, attachment blocking, Software Restriction Policies, and so on. We put a better lock on the front door so that you don't have to throw out all your kitchen knives.
Obviously this simple threat model doesn't apply if you have an ActiveX component marked "Safe for Scripting," or if you develop managed code that allows partially-trusted callers, or if you accept any kind of untrusted communications from other machines across the network. In those cases you have much more complicated threat models and you do have to start worrying about what happens when someone with restricted permissions talks to your application's OM, and it would be great for you to look at how you can reduce your attack surface. But for a rich-client full-trust-only application like Office 2003, these kinds of threats simply don't apply.
Finally, if you're still not convinced, then think of it this way: Outlook is nothing special. Sure, it's a great e-mail client and I spend most of my day using it, but at the end of the day it's just a piece of software. Whenever a destructive virus comes around, you don't see the whole world demanding that Microsoft remove the DeleteFile API from Windows because it makes it easy to write file deletion viruses; that would be ludicrous. It's the same with viruses like Blaster or Slammer -- nobody asked Microsoft to pull networking from Windows just because there were viruses that propagated across the network (although some people have asked for "raw sockets" to be pulled, even though they are a standard part of most modern operating systems).
Another angle: A recent InfoWorld article shows the prevalence of spyware and adware on users' machines; a lot of that stuff is "willingly" installed by the user as part of some other application (typically file-sharing software), although a lot of it is also "accidentally" installed by users who do not read the (very poorly designed) IE download dialogs (which will thankfully be fixed in SP 2). These programs are probably more "destructive" to the average user than any e-mail virus, since they completely violate your privacy (monitoring web surfing, stealing passwords and credit card numbers, etc.), can include "backdoors" to allow later access and complete compromise of the system, and often cause instability of the OS.
And none of this has anything to do with Outlook, or, indeed, any kind of e-mail program. It has to do with the users' basic right to install software on their own computer and make bad trust decisions in the process. This is the problem that we need to fix long-term; not the ability of software to expose powerful, flexible object models that can be freely and productively used by suitably-trusted clients to build great customer-focused solutions. And of course, since trust is inherently a social problem, not a technological one, so the best we can do is educate users and guide them into making good decisions; we cannot make decisions for them.
There is no silver bullet.