Bruce Schneier posted about an eWeek article that details the proposed new ActiveX Installer Service. I was a little disappointed to see that Bruce thought it was a bad idea. I think this may be because Bruce doesn't know how bad the current situation is.
This is really an improvement over prior Windows versions, not a "poking holes" in security deveopment. It has very little to do with User Account Control at all. It's not bad, per se. It's better than things were before. I wish, in fact, that it was being backported into the current Windows XP environment.
In a presently-deployed network with Windows 2000 and Windows XP client computers and users who do not have local Administrator rights, users cannot install ActiveX controls. This ends up being a huge pain, a sink of manual labor, and clearly isn't a situation that was very well thought-out by Microsoft at all.
Most of my Customers, for example, have some web-based application that requires certain ActiveX controls to be installed to function properly. In most cases, I can deploy Windows Installer-based (MSI) packages for the controls they need (mainly Adobe Reader and Macromedia Flash), and the headache is taken care of.
For my Customers that use more "boutique" ActiveX-based applications (an outsourced payroll management system that is ActiveX-based, an "ASP" document control repository interface, etc) that are not distributed as MSI files, I have two (2) remotely viable choices in getting the controls deployed onto their PC's, and neither is very good:
(1) Capture all the registry settings and files installed during the browser-based installation with a "packaging tool" (or "by hand") and build an MSI package. Hope that I got everything right (since I don't have source code to their control) and do damage control when I screw up some nuance of the installation on a subset of the, potentially, hundreds of different PC configurations that the control may deploy onto. Update this package each time the manufacturer "updates" the control.
(2) Logon to the PC manually w/ an Administrator credential and install the control. Attempt to verify and hope that the control doesn't inappropriately store anything in the user-specific portion of the registry such that the control won't function properly when the user attempts to use it. Do this to each PC that uses the control each time the manufacturer "updates" the control.
The third choice, of course, is just to weaken the security, typically by giving the user local Administrator (or, sometimes, Power User) rights. That's totally unacceptable to me, so most of the time I end up doing a combination of the first and second above, depending on whether the control needs to be on three (3) or three-hundred (300) PC's, and depending on the frequency of "updates" by the control manufacturer. (Don't even get me started about these idiotic software firms that think that "release early, release often" is a good idea for this type of application...)
The "solution" that Bruce posted about alleviates these problems above and creates an interface that I can use to grant access for "normal" users to install ActiveX controls that I've approved. Let's be clear: I don't _like_ the fact that we need this at all-- i.e. I think Microsoft shouldn't have browser-based control installation and _ALL_ installations of software should be managed by a service like the Windows Installer. Since nobody at Microsoft values my input on this issue (and, apparently, the input of every other clueful corporate network admin), I'm stuck favoring this solution only because it's leaps and bounds better than the alternative and will end up saving my Customers money.
It seems pretty clear to me that Microsoft doesn't do a lot of thinking about how large corporate Customers are going to integrate "new innovations" into their deployments. For everything that Microsoft does to add management interfaces, automation systems, and centralized administration tools, it seems like most cool new "innovations" get marketed heavily to ISV's who end up deploying them into systems that my Customers interact with. These "innovations" usually end up being the equivalent of prototypes that got shipped, and they aren't engineered heavily enough for real world deployment, use, and management.
In the case of ActiveX controls, the majority of the ISV's I've dealt with don't have any coherent strategy for deploying the control onto large numbers of PC's in a clean, manageable way, primarily because Microsoft didn't drive the point home clearly enough to the ISV's developers that deployment is an important issue. This feature, at least, gives us some mechanism for controlling the insanity.
