Load ActiveX Controls on Vista Without Administrator Privileges

This seems like a bad idea to me:

Microsoft is adding a brand-new feature to Windows Vista to allow businesses to load ActiveX controls on systems running without admin privileges.

The new feature, called ActiveX Installer Service, will be fitted into the next public release of Vista to provide a way for enterprises to cope with the UAC (User Account Control) security mechanism.

UAC, formerly known as LUA (Limited User Account), is enabled by default in Vista to separate Standard User privileges from those that require admin rights to harden the operating system against malware and malicious hacker attacks.

However, because UAC will block the installation of ActiveX controls on Standard User systems, enterprise applications that use the technology will encounter breakages. ActiveX controls are objects used to enhance a user’s interaction with an application.

Tags: computer security, Microsoft, vulnerabilities, Windows

Posted on July 3, 2006 at 8:31 AM • 42 Comments

Comments

katre • July 3, 2006 9:06 AM

Also, since LUA makes it too hard for users to accidentally trash their systems, a new feature called DEA is being added. DEA stands for Delete Everything Accidentally, and will wipe all hard drives on the system, with only a single button-press!

Curmudgeon • July 3, 2006 9:22 AM

Excellent! One hopes this will lead to a simple way to flip the “kill switch” remotely without needing Administrator access!

cea • July 3, 2006 9:36 AM

It seems MS has just reinvented the setuid bit:

” … Fathi said the company is also considering automatic shimming for legacy applications that may never be changed to work with the default UAC settings. “

JakeS • July 3, 2006 9:53 AM

I think the eWeek story is muddled. If I understand it, MS is providing a good solution to a small but irritating issue. I don’t see any problem with it.

Most corporates try to have as many users as possible running as standard user – without admin rights – for obvious reasons. The problem now is that standard users under W2K or XP can’t install ActiveX controls (if their sysadmin has set their security level sensibly). So “enterprise applications that use [ActiveX] technology” already “encounter breakages” right now, not as a result of Vista. Corporate web application developers want to be able to install ActiveX controls more quickly and easily than by deploying a special installation script each time, which is a pain in the butt. If the story is correct, MS’s solution is to permit installation of ActiveX controls from designated sites which, if sysadmins have any sense, will be on corporate intranets and under proper control. Sounds OK to me.

Joseph • July 3, 2006 10:06 AM

I agree with JakeS.

Joe Patterson • July 3, 2006 10:10 AM

Fascinating. I wonder if UAC will survive at all. For a while all I’ve heard is that the intention is good, but the implementation is extremely annoying for users. Now they’re starting to poke holes in the security, which is sort of like making “just one small hole” in a dam. Now that the security’s gone, all that’s left is user annoyance.

Microsoft is facing a hard problem here. In general, users don’t want to put effort into security, but it’ll only work if they do. Unfortunately, faced with a hard problem, they’re failing to provide even mediocre solutions.

Brian S • July 3, 2006 10:30 AM

I think it is important to view this for what it is: a solution to a real problem (experienced by beta testers and corporate customers alike in Vista and pre-Vista standard user scenarios). This solution also carries the opportunity to be exploited because it is designed to circumvent a previously implemented security control.

Does it make sense for MS to release a product that breaks business apps? Of course not. The security purists will argue that the enabling of a feature to “degrade” security is A Bad Thing (TM), but in the end the question really is: If only business and advanced user SKUs (Business, Enterprise, Ultimate) even have this option and those are the most likely to have the technical know-how to use it properly, while leaving the “normal home user” with UAC as default, did they hit a reasonable compromise?

I suppose only time will tell.

Anonymous • July 3, 2006 11:16 AM

ActiveX controls are objects used to enhance a user’s interaction with an application.

Ah, ah, good one.

sidelobe • July 3, 2006 11:26 AM

Our security models not keeping pace with the changing usage models. We’re making incremental changes to security models while making deep fundamental changes in how our computers are used, maintained, and networked. This appears to be a tweak of a tweak, in response to corporate users and managers who are also not keeping pace with changing usage models.

The designs are available, but IT departments are still thinking in terms of the 1970s.

I also find it amusing that when I opened the story, eWeek presented me with a Microsoft Ad proclaiming “Trojan Horses Turned Away At The Gate”.

Carlos • July 3, 2006 11:28 AM

I fail to see the problem. How is this worse than any other automatic software update mechanism used in a corporation?

Sensible corporate admins will limit users to running ActiveX controls signed with the corporate key (you can do this in current versions of Windows), so you’d have to subvert the software distribution mechanism and the corporate key to take advantage.

Evan Anderson • July 3, 2006 11:37 AM

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.

JakeS hit the nail on the head. 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 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 “botique” 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.

Jeff Kell • July 3, 2006 12:31 PM

Take the statement “because UAC will block the installation of ActiveX controls on Standard User systems, enterprise applications that use the technology will encounter breakages.”

Now replace “enterprise applications” with “spyware/adware/malware/rootkits/bots”.

Any concessions they make for the former can also be leveraged by the latter.

It is ActiveX that is broken from a security standpoint, and applications that depend on it.

GLG • July 3, 2006 1:16 PM

It doesn’t seem like a bad idea to me, though it does depend entirely on a correct and complete implementation. From the original article:

“Before installing the ActiveX control, the Installer service will check to see if the Host URL of the CODEBASE is defined and listed in Group Policy and if it is allowed. If the service policy permits the install of the ActiveX control, it will create an instance of the Internet Explorer ActiveX installer object to be used to install the control.”

Gee, that sounds almost exactly like the security policy files that Java has been using for years, on Windows, Linux, and Mac OS X.

Java’s security policy files grant privileges (identified by name) according to codebase (whole or partial URL, including localhost file-system URLs). As long as the chain of trust isn’t botched (a policy error), it works great. The same policy files also work great with Java Web Start, where entire applications, sometimes including native code, can be downloaded and used dynamically. All grants of a privilege are ONLY given to SIGNED and AUTHENTICATED received code, so unless it’s signed, it stays in the sandbox, regardless of the policy or codebase URL.

On a localhost with Posix-style security (e.g. Linux, Mac OS X), Java’s security policy files are owned by root and not writable, so unless you gain root privileges, the policy files remain trustworthy. A fundamental security premise is that a Standard User can’t gain root privileges, so the policy files can’t be compromised. However, these policies still control the granting of privileges like installing new code locally, thus extending the trusted code base.

In search of more detail, I followed the article’s cited link to MS’s UAC blog:
http://blogs.msdn.com/uac/archive/2006/06/14/631416.aspx

where I read even more technical details.

It still sounds like Java’s security policy files, and other than the need to view everything as an “install” instead of just a privilege grant, it seems exactly like the security regimen used with Java Web Start, which allows downloading, using, and updating mixed Java code and native-code libraries. With Java, it’s all based on signed files in addition to the localhost’s security policies, so I see no major problems with the basic design.

Of course, since the MS implementation is newly implemented, it’s difficult to tell what the quality will be. That would be my major concern. A new security implementation is bound to have errors, and since it’s such a bright shiny target to aim for, you can bet it will be assaulted from all sides.

So at a basic level, I’m thinking: “Big deal, Java’s been doing this for years,” which seems to demonstrate the effectiveness of the model. The only news is that it took Microsoft this long to figure it out. They’re usually much quicker at innovating off other people’s work.

tc • July 3, 2006 2:27 PM

I can’t believe the responses. Do you not get security? ActiveX controls should only be installed by administrators, period. There are automatic scripting tools for corporations to use to deploy controls after proper testing. IE has had a feature in it to only allow administratively approved controls.

The biggest problem IE has is its ability to install ActiveX controls without user intervention. Now, it appears people don’t like it when they have to intervene. Get over it. User intervention is the proper response. One has to remember ActiveX controls do not operate in a sandbox. They have full access to the system (unlike Java Applets, Flash Applets, etc.).

The solution to the problem is not to allow the user to install ActiveX controls, it is to have a proper review and testing of ActiveX controls prior to deployment and then use a proper deployment script that will set the control up properly. To allow users to configure their systems, in a corporate environment, means you have thrown security out the window.

Doofusdan • July 3, 2006 2:36 PM

I am also not sure why this is a bad idea. Seriously, I’m going for dialog here: can someone explain how this is bad?

It’s not on by default (or even included in most versions of Vista). For an enterprise, if you turn it on, you manually whitelist sites using Group Policy and allow clients in your org that visit a particular URL/fqdn to install ActiveX controls from that location.

Beats the heck out of deploying in advance those controls to everyone who might eventually need it, and then updating those controls as installed on the computers of everyone who’s ever used them, just to get a fix deployed.

So what’s the problem? Why shouldn’t I turn this on in my organization? How does its presence in Vista put others at risk if they’re not going to use it?

Doofusdan • July 3, 2006 2:40 PM

To clarify where I’m coming from: imagine an enterprise where most people run with admin rights. Imagine that when deploying Vista, we are going to do it with most users NOT having admin rights.

Now think about how useful this feature is – it takes care of one of the major stumbling blocks to removing admin rights in a way that does not greatly increase the burden of supporting ActiveX based web applications.

So, that’s why I think this feature will be a net plus for security in the enterprise: it helps get over the hurdle of “my users have to have admin rights to use their computers effectively!”

Anony moose • July 3, 2006 2:44 PM

Ubuntu Linux is free and sent to you for free: https://shipit.ubuntu.com

Or choose from one of the several hundred flavors of Linux for a distribution that meets your needs, for free.

Stop funding a convicted monopoly!

Nathan • July 3, 2006 3:19 PM

Why why why Microsoft just can’t dump ActiveX ENTIRELY? No matter what security systems they build to Windows, ActiveX is and always will be the most insecure POS ever built. Has it ever been used in any else than infecting your computer with viruses/worms/whatever or taking over (spam zombie)?

Jojo • July 3, 2006 3:28 PM

One of the reasons I switched to Firefox was because FF doesn’t support Active-X controls. I still have to use IE sometimes for sites that depend on Active-X but I have my security set to prompt me for installation of any Active-X controls. I only allow installation if I feel comfortable with the site.

offtopic • July 3, 2006 3:35 PM

“UAC”

So, Microsoft finally admits that they are about to unleash hell on unsuspecting people. I mean, using the Union Aerospace Corporation acronym is just a Doomed idea…

LazyAdmins • July 3, 2006 4:56 PM

I agree that this is a terribly bad idea. Unfortunately, Microsoft is folding under the pressure of a few lazy network administrators, that don’t know how to properly manage their networks.

I have managed several enterprise networks and there is no reason for users to have admin rights or the ability to install ActiveX controls.

Applications and especially ActiveX controls should only be installed by network admin level staff as part of contolled application roll-outs. Regarding testing, any good network admin will properly test any application, or ActiveX control, before deploying it to the user base, so any problems with non-Admin rights and ActiveX will be discovered and fixed. Also, in enterpise networks, I have found that major applications get updated at most once a year (similar frequency for even the “one-off” apps), so users don’t need app updates which require ActiveX controls to be installed on a daily basis.

The only reason I can see for Microsoft to even entertain such an ill-conceived plan is that some lazy, under-educated “high-level” network admins have undo influence.

Peter • July 3, 2006 8:51 PM

ActiveX controls are holes in the operating system. In order to work, they become a part of the operating system, and thus easy to subvert. If a securable operating system is a goal, then no technology such as ActiveX can be permitted.

Todd Knarr • July 4, 2006 1:58 AM

LazyAdmins: I think the basic problem is that a lot of major ActiveX controls that admins want to install (or need to install) aren’t designed to be installed as part of a controlled roll-out. They’re designed only to install themselves when the user hits a Web page. Yes it’s bad design, but it’s what the admins have to live with. Given that sort of design problem, MS’s solution’s really the only one that’s workable in practice.

Not, mind you, that I think their solution’s a good one, because it’s not. It’s going to have holes in in that’ll be exploited by malware. I remember the problems with the Local Network zone and numeric hostnames, for example. I also fear the hacks admins will need to use to handle ActiveX-based outsourced Web apps where the admins don’t know the servers involved and the servers may change from one use to the next. It’s not a good solution at all, merely a neccesary one. I hate that particular combination with a passion.

Christoph Zurnieden • July 4, 2006 6:08 AM

It might be a restriction of my knowledge of the english language, but after reading the article teh question left: what changed exactly?
Is it just the capability to install some ActiveX snippets which are merely whitelisted by IP/hostname and not even cryptographically signed?
Or did they make it right this time and ActiveX drops all privileges at runtime and is carefully sandboxed too?

tz • July 4, 2006 9:44 AM

I don’t think it is a “bad idea”, but it ends up becoming pointless.

UAC was designed as a steel security door to fix the problems with everyone having admin privileges to do anything.

As they find places this breaks the prior insecure model, they put a “doggie” door, first letting through small dogs, but eventually great danes and burglars as they find something else which needs it.

The codebase URL can point to an infected machine, so while you might not get something from a phish email, it won’t stop an internal infection cascade now.

Java applets at least still run in a sandbox and can be limited. ActiveX is either disabled or “part of the operating system”. The latter was a design decision by Microsoft long ago, but it affects what is possible today.

I still really don’t understand why they must “install” an app using privileges – but that must be another microsoft-ism. Most mac and unix applications and widgets just install (and uninstall). The few that require special privileges ask for them, but they are limited. The fact that all (or too many) ActiveX controls need admin privileges (and apparently run as admin) says their security model is still wrong.

They have a trilemma:

Users have taken advantage of insecure design as much as the malware writers.
They need to tighten security, but it is a tradeoff based on how much they want to break.
They can’t or won’t design in emulation layers (for things like virtual sandboxes) so things can avoid running everything as administrator/root, or split the layers so ActiveX can be installed and run (as safe as any user exe) without privileges.

Either abandon the users, do a series of “restrict and poke hole” operations, or do a fundamental redesign.

At the rate they are going, Vista will be little more than XP with a facelift (which itself was a facelift on W2K, which was just WNT with USB support, and WNT wasn’t itself that bad for security, at least without IE).

After their year concentrating on security, they should have realized that they needed to fundamentally restructure things. They are already demanding powerful hardware for the eye-candy. But it wouldn’t be easy.

Jonsey • July 4, 2006 11:45 AM

“ActiveX controls are objects used to enhance a user’s interaction with an application.”

I thought they were for 0wning Internet explorer users, silly me 🙂

Will • July 4, 2006 2:06 PM

Professional software engineers should only use COM (i.e. ActiveX) when they need their software to interoperate with software from another company. I.e. it’s usefulness is limited to BIG software projects, and even then, it should only be deployed at the inter-system boundaries.

Developing with ActiveX/COM is only really pleasant if you are using Delphi or Visual Basic; from C++ or C the experience requires voodoo programming at it’s worst.

In my experience, those who choose to use COM/ActiveX heavily generally regret the decision.

Time will tell, but .NET does seem to be an improved way to develop language independent networked applications.

For me, Vista seems like a good opportunity to start deemphesising ActiveX/COM and pushing .NET across the board.

Peter • July 5, 2006 12:27 AM

It might be a restriction of my knowledge of the english language, but after reading the article the question left: what changed exactly?
What should have changed is that the desktop gets locked down. What happens when you install an ActiveX control is that a number of registry entries must be made (that’s just how ActiveX works), and you need power-user or administrator access to do that. Because ActiveX controls are part of the operating system, they won’t run with the permission set of the user. The setting that says an ActiveX control is “safe for scripting” (which means it can be called from any web page) is a setting that is made by the author of the ActiveX control. “Oh, I am perfectly safe” says the bandit pointing a gun at you.

B-Con • July 5, 2006 4:42 AM

So, basically, Microsoft put in layered user permission system to restrict application permissions and then provided a way around it?

Richard Braakman • July 5, 2006 6:24 AM

So the question becomes… how hard is it for someone with a user account to spoof one of the whitelisted sites?

If the whitelist is by domain names, it doesn’t seem very difficult.

Pat Cahalan • July 5, 2006 1:39 PM

This seems like a bad idea to me, as well.

Microsoft put a major push on active directory and group policy as “the right way” to run a Windows house. You manage your users and your computers (and by extension, your software) through those two central tools. This featurette is enabling a new path for software management (distributed and controlled by the user), which goes counter to the central management philosophy of AD & GP.

If you’re going to be a desktop operating system vendor, stick to that. If you’re going to move into enterprise management tools, design a methodology for those tools and then stick to it.

InfoJunkie • July 15, 2006 6:48 AM

Hi,

I won’t bother to comment on some completely irrelevant and very ignorant remarks about developing ActiveX in C++/ATL but I would like to point out the other side of UAC.

Bruce has picked on the installation of ActiveX in Vista, which forces everyone to run in Standard User Mode.

I believe UAC is bad not so much as the ActiveX installation, which is part of it, but to support many extremely poorly written programs that do not conform to Windows Security Model, published prior to the release of Win 2000.

Keith Brown on his web site keeps a Hall of Shame of these program.

It is sad to see Vista is aiding these program and allowing them to run transparently.

In Vista everyone is running in Standard User mode, and as such, without UAC, these poorly written program would fail mysteriously, misbehave or crush immediate (the best scenario to users).

These programs writes data to everywhere, HKLM, “Program files” area, Windows directory, as if the OS is still like Win3.1. Some uses over-zealous permission to do a simple job.

Many developers, including many big name companies, are ignorant of this specification. It has taken Quicken till their 2005 version to have corrected this problem, 5 years after the release of the spec. I only wish Microsoft would find a better way to force these bad programs to correct their mistake.

Many of these developers are not only ignorant of this spec but also developing them in Administrator mode. As such they do not even know if they have committed a mistake. Users who pay money for their products are getting the raw deals.

Visual Basic 6 is one of those programs that will not run in LUA but it is an obsolete product now. AQTime4, the latest version, from Automated QA will not run in LUA. When I pointed out to them their failure was trying to write to HKLM trying to create the COM registration information (after installation), they refused to admit fault.

UAC is going to give these developers more sand to hide their heads in it. It is totally silent and I don’t think they writes to event log of the perpetrators. In this respect, I believe it is a BAD thing.

Unless Microsoft has changed the early design and implement decision of UAC, it is not supported in Win 64 and the last I heard from MS, there was not plan to have this in the future.

Anonymous • August 11, 2006 7:15 AM

Anonymous • August 11, 2006 7:16 AM

hey hey hey hey hey hey hey hey hey hey hey hey hey hey hey hey hey hey hey hey

Les • August 11, 2006 8:19 AM

You cannot have your cake and eat it too.

Anonymous • August 26, 2006 1:03 PM

@Carlos:

“Sensible corporate admins will limit users to running ActiveX controls signed with the corporate key (you can do this in current versions of Windows), so you’d have to subvert the software distribution mechanism and the corporate key to take advantage.”

Bzzt, thank you for playing, but that is not the correct answer. Last I heard, ActiveX controls have signed code, but that doesn’t mean there aren’t vulnerabilities in that code that can be exploited remotely. All it is is signed code, like when some security-conscious developer signs the tarball with GPG/PGP.

If you read the ActiveX writeup on http://www.computerbytesman.com, you’ll find a survey of function entry point symbols in OEM ActiveX controls that shipped with a laptop include functions for reading arbitrary files on the file system, writing to files, and occasionally executing arbitrary programs.

Since trusted ActiveX controls can be invoked from web pages in many cases, a malicious web page could basically do whatever it wants.

Coupled with the fact that some ActiveX/COM/WinDNA (whatever they’ve named the unpopular beast this week) are written in languages that don’t do bounds checking, there’s a field day for buffer overflows.

Andy • March 3, 2007 8:38 PM

Regardless of whether Microsofts new approach is correct or not, the truth is IT doesn’t always make the decisions on what software, or in this case, websites the business is going to use. I am constantly confronted with ActiveX controls that need to be installed and I don’t have much to say about them. I resort to regsvr32 and psexec to handle it most of the time. MSIs are nice and a cleaner way to deploy, but generally more trouble. Microsoft can only do so much to encourage developers to build better software. The truth is, if Vista can’t run my “current” business critical applications, I can’t install it; Microsoft knows this and built in work arounds. Seems like everyone is just trying to work around software vendors’ cheeply written software.

sn • May 28, 2007 12:27 PM

Developing with ActiveX/COM is only really pleasant if you are using Delphi or Visual Basic; from C++ or C the experience requires voodoo programming at it’s worst.

In my experience, those who choose to use COM/ActiveX heavily generally regret the decision.

Time will tell, but .NET does seem to be an improved way to develop language independent networked applications.

For me, Vista seems like a good opportunity to start deemphesising ActiveX/COM and pushing .NET across the board.

Posted by: Will at July 4, 2006 02:06 PM

How is that??

steve • June 30, 2007 1:34 PM

Those who are against this idea obviously have no idea what ActiveX is. I think most of you just think it’s some web technology. ActiveX is just an extension of COM (has an additional interface) which has foundations in OLE 2. Many(!) applications use ActiveX from displaying grids to user interface controls, FTP components, reporting components (Crystal Reports, for example), etc. It really is an issue that MS needs to address.

steve • June 30, 2007 1:40 PM

BTW, I am not saying ActiveX itself is not problematic (since it does become part of the OS) but that MS had to make it so software using ActiveX should work under restrictive rights.

Here’s the thing. Employees won’t be able to install activeX but they will be able to use them without issue. It is up to security to make sure that what is installed on the employee’s PC in the first place is safe. Once that is established then what’s the issue? The employees can’t install ANY software let alone ActiveX and I doubt a reputable company is going install a Kill switch for the heck of it.

midNightBoots • October 25, 2007 11:34 PM

Wouldn’t it be nice if Microsoft could just create a generic .NET COM Interop wrapper that administrators could configure for varying levels of “constraint”?

Surely the Magi in Redmond can come up with a way to put a “facade” on their own legacy technology to make it play by the new rules of a managed runtime!

This would supply companies (and home users) with the elusive “sandbox” that MUST exist to protect against expensive (or fragile) infrastructures.

If they want to keep pushing wave after wave of new technology on frustrated customers (and their IT teams) they will have to get a lot more thoughtful about ways to minimize the toll of transition.

Without this kind of “Legacy Sandbox Solution” we must, as developers and IT support professionals, put arbitrary web-base COM (ActiveX plug-in) requests on the “NO FLY LIST”.

The current situation isn’t just annoying developers, administrators, and users; it’s breaking the Internet!

\’-)

Dan • June 25, 2008 5:42 AM

If the company has any sence then they will test the service packs before release anyway i know i certainly do and will be installing alternative security solutions to allow this update

Schneier on Security