For years, many security consultants and well-meaning guidelines have recommended completely disabling ActiveX in Internet browsers (mainly Internet Explorer) to prevent a particular type of Web client-side attack. Running a browser without ActiveX enabled can be a frustrating experience for end-users, as many popular and legitimate Web sites use ActiveX to enhance the user's overall experience.

Barely a week goes by without one or more ActiveX controls from various vendors being declared unsafe, so I can understand the caution. You should always disable unneeded and unauthorized software, but running a browser without ActiveX enabled when other more reasonable alternatives exist is throwing the baby out with the bathwater.

(Disclosure: Although I work full time for Microsoft, everything I say here could equally apply to Sun's Java.)

Yes, hundreds of ActiveX controls have been found, over the last decade, to contain buffer overflows or to allow malicious behavior. But with a few exceptions, the problem isn't with the ActiveX platform itself, but with insecure program code passed along using ActiveX mechanisms. Sometimes the ActiveX controls are downloaded by users, but problematic controls are just as likely to be preinstalled by hardware and software vendors.

ActiveX is a platform, not a language. No one codes in the ActiveX language. ActiveX is a popular way for a software vendor to transport its program (normally in .CAB, .DLL, or .OCX file formats) from a Web site, then install and launch it in a user's browser session in an almost seamless manner.

There are many other methods to download and install Internet-based code, but ActiveX is fairly easy to use, integrates well with multiple Internet browsers, and contains many native security mechanisms. For one, vendors can sign their ActiveX controls with a publicly trusted digital certificate to confirm to the end-user that the program they are receiving is indeed from the purported vendor. There have been a few malicious uses of digital certificates over the last decade, but the inappropriately used certificates are quickly revoked when discovered. Overall, the publisher identity system works pretty well in identifying the originating software publisher, when users pay attention to it.

But unfortunately, a digital signature doesn't guarantee that the control won't do something unauthorized to the user's system or that it doesn't contain an exploitable vulnerability. No programming language or Internet transportation method can do that. ActiveX gives vendors one way to transport their program from source to destination, but it doesn't absolve the vendor of using SDL (secure design lifecycle) programming.

Now, it is completely valid to ask if ActiveX's ability to seamlessly download and integrate programs within the context of a browser is a safe thing in today's scary Internet world. But if you're going to identify an Internet programming mechanism involved with more Internet crime than another other mechanisms, you would single out JavaScript. JavaScript is involved in nearly 100 per cent of browser-related, client-side attacks, including the ones involving ActiveX, and you don't hear popular calls to get rid of JavaScript.