Post a Comment
... would be for Microsoft to certify ActiveX applications, sign them, and only run properly signed controls.
Of course, there are a lot of corporate intranet sites that require ActiveX controls so, unless Microsoft is willing to alienate them, completely disabling ActiveX capability by default would be challenging -- and would result in significant criticism from customers, IMO.
You could get around that with network policies.
Right now, IE looks at the list of trusted CAs to work out whether a signed control should run or not. All MS would have to do is create a separate list of €trusted CAs for ActiveX€ and only add its own certificate to the list initially€"but, as with the normal trusted CA list, it would allow corporate administrators (or end users, if they really wanted to) to add their own CA certificates to the list.
I suspect, though, that MS wouldn't do this right now€"it seems to be extremely wary of appearing like it wants to create any new monopolies, even if the reasoning and justification is fairly sensible.
ActiveX is the main originator of Windows and IE being a pain in the ass for their users in regards to security. ActiveX holes were countless and made this technique soon look like a parody of reason. And this didn't came as a surprise, almost every real security expert back then expected security problems from ActiveX.
Now let's see what today's "experts" have to tell in this article:
"Disabling ActiveX would in many ways break the Web, especially in the areas of rich media and rich Internet application consumption. This was the fear a few years back when Microsoft was sued and the plaintiff argued that ActiveX violated their patent," Swenson told eWEEK.
Bullcrap. Disabling ActiveX would in many ways make the web more secure, convenient and interoperable -- if even anybody cared.
I haven't had any ActiveX since 2002 and never missed it; it's major job being vendor lock-in again anyways. But I could see the damage it made all over the place. Get lost, ActiveX!
Activex is (one of) the main originators of IE being a pain in the ass for users of other browsers and OSes, as well. (The other being their sucky and incompatible javascript implementation.) Arguably, IE users get what they deserve. But I never asked to be locked out of sites that my users *need* to do their daily work, because the sites use incompatible javascript and activeX controls. CSS compliance is just the tip of the incompatibility iceberg. Seems to me MS is getting a *lot* of PR mileage out of IE8 supporting CSS, etc. better... while the real barriers to competition continue on. What good is it for a site to render properly if it does not *function* properly, or at all, if you don't use IE?
I was kind of excited about this IE8 stuff at first. But then I sat down and considered what practical benefits it promised for me and my users. And I'm afraid that the answer is "precious little". I have to admit that it is a particularly shrewd PR move by them, though.
Edited 2008-03-08 14:29 UTC
I can't agree with you more.
The fact that MS is able to take a serious lose of credibility (i.e. the EU ruling and subsequent fining), do something they should have been doing from the start (actively support open standards instead of forcing their crippled implementations down everybody else's throats) and then turn that into a victory by releasing a slightly better product than the last one truly is a master piece of PR spin. No wonder they are top dog in the industry.
ActiveX sucks, no doubt about it. Nothing was stopping MS from using a similar plugin mechanism to Netscape's back in the day thereby allowing people to at the most make a few changes to their plugins. Instead, everybody had to write a plugin for each competing browser.
Fast forward to today, and nothing has changed except in as much as we have seen the rewards MS has reaped with their ActivX gamble, i.e. security nightmare. ActiveX drive by installs where the biggest security problem in the IT world when I was growing up and has directly led to our current situation with bot nets, spammers and phishing scams.
I'm all for MS releasing a better browser, as competition is always a good thing in my eyes, but it's time MS laid that ugly architecture to bed. Even less is stopping them from using Mozilla's plugin architecture today, and for all those poor fools who still have a need for it in their corporate intranets, I'm sure MS can russel up an ActiveX plugin for em.
ActiveX wasn't the problem, it was ActiveX COM/COM+ objects. It was a bad idea from the start, the reason it works with Java is that the JVM gives you the ability to sandbox the code coming through the browser really well. Sandboxing something like COM must have been a nightmare to even try, its no suprise they didn't succede that well.
I just posted this somewhere else, but there is no reason to do anything new with activeX objects anymore. We have silverlight for public facing rich application interfaces, which is lightweight, cross platform, and specifically designed for that. We have had oneclick deployment for years now, which is for corporate intranets, to deal with the pain of deploying rich thin clients accross a network. And now with .net 3.5 we have XBAPs (XAML Browser Applications), which is basically a rich app that lives in the browser, for completely painless thin client deployments accross intranets. All three are .net, which allows them to be sandboxed a hell of alot easier, and with greater success.
I agree with you guys (actually not arguing for once, just wanted to offer some knowledge on the technology), what they should do is make activeX something you have to download. ActiveX is for legacy apps anyways, and if you are going to bother upgrading them to support ie8, you may as well go all the way and write an XBAP for your thin client.
The business critical sites that are the biggest pain in my rear are the one's that couldn't agree with you more. They believe that there is no reason to do anything new, period. You phone them up and tell them that Firefox is a significant player, nowadays, and that they need to support it. They tell you that everybody uses IE and that nobody uses Firefox. You ask what makes them think that, and they reply that their server logs show that almost everyone uses IE. You point out that their site doesn't even remotely work, won't even let you log in, with anything other than IE, and they fail to see any significance to that regarding their web stats.
They have an investment in their IE-only application, and an effective monopoly in their own domain, and they don't want to change anything. The client involved does service on restaurant equipment, and the brain-dead company I'm referring to has a stranglehold on service-oriented web services in that industry.
If they told their customers that they had to download several plugins per machine to make their crap applications work, the customers would do it because they had to.
We run IE under Crossover Office, when we have no choice, out of necessity. And it burns me up to think that we are contributing to the pile of evidence in their web logs that indicates that everyone uses IE.
BTW, I value your opinions and knowledge, and do not consider any of our exchanges to have been arguments.
I didn't bother to read the article, but the very premise is idiotic.
ActiveX is the plugin mechanism that IE uses. So, disabling ActiveX would cause you to disable Flash, Quicktime, PDF, WMP, Java (IE's JVM is an ActiveX component), and any other legit plugin you can think of. Which would break popular sites like YouTube (since it relies on Flash), Xbox.com, Apple.com, ESPN, CNN, MSNBC, etc, etc, etc.
ActiveX, as a native plugin architecture, is no less secure than any other native plugin architecure (by "native" I mean compiled to the metal binary code). The security hazard of ActiveX had been the ability for web pages to download and install ActiveX controls that they needed on the fly, asking the user to OK it with a simple message box (the exact behavior is dependent on whether the ActiveX control is signed by a legit authority or not), and various techniques were used by bad guys to trick the user into OKing these installs, or exploiting some IE bug to do drive-by installs. But this sort of thing has been curtailed drastically since XP SP3 (with the info bar, the user has to jump through lots of hoops to install an ActiveX control); drive-by installs are largely a thing of the past. Also, let's not forget that on Vista, IE runs in its own sandbox to begin with, limiting the mischief that a native plugin could do anyway.
Now, maybe one could advocate disabling the downloading of ActiveX controls, but disabling IE's plugin architecture altogether makes no sense.
Edited 2008-03-08 18:33 UTC
I think what they meant is ActiveX COM objects, which have a horrible track record when it comes to security. Since their acceptance is almost at that of java applets, I doubt it would effect many people outside of corporate intranets.
At this point though, support is mostly for compatibility reasons anyways. If you are doing a public facing rich application interface, silverlight is the redmond sanctioned way to do it nowadays. If you are doing a browser based thin client, you could either do a winforms one-click install which gives the (almost) painless deployment experience, or an XBAP (XAML Browser Application) which is basically the same idea as ActiveX COM/COM+, just .net, and with way better security mechanisms.
How do you distinguish ActiveX COM objects? All ActiveX controls are COM objects, to my knowledge.
I guess one area of problem is that the ActiveX controls are stored, in a sense, in the same namespace as other COM controls. It's possible for a careless developer to accidentally allow a control to be instantiated in the browser even though it hasn't been designed to the necessary level of security to run there (this is the 'Mark control as safe for scripting' setting).
I agree with your statement that we ought to move to .NET-based corporate applications rather than ActiveX-based ones. .NET is much easier to program and thus likely to be more reliable.
Silverlight might be "redmond sanctioned", but the Silverlight "engine" itself is an ActiveX control (just as the Flash, Quicktime, WMP plugins are), and is even listed as such in IE's Add-ons Mgr (it's the "AgControl" add-on), so disabling ActiveX disables Silverlight (and Flash, et al).
http://blogs.zdnet.com/Burnette/?p=297&tag=nl.e622
"agcore.dll (2.2M installed) - This is the core ActiveX control that is responsible for Silverlight rendering and events, including audio and video decoding.
npctrl.dll (460K) - A wrapper for agcore.dll that makes it run inside Firefox."
And PlatformAgnostic is right, that all ActiveX controls are COM objects.
Now, a scenario that I *could* see is that certain ActiveX controls are "blessed" (Flash, Silverlight, QuickTime, WMP, Real, JVM, WindowsUpdate, DivX, etc) and all others must be downloaded and then installed manually (i.e. not through ActiveX's download/install mechanism). This would be OK, because you're right, nobody makes "applets" as ActiveX controls, they instead make applets that run on top of Flash/Silverlight/JVM engines, which themselves are loaded as ActiveX controls.
Except for one case, that of intranet ActiveX Controls used by business, and the employees (or thier IT dept) can manually install those controls.
Edited 2008-03-09 03:28 UTC
I just checked my beta install for IE 8, and last time I check ActiveX security setting for the INTERNET zone in the browser you could disable all of this stuff directly.
To me that means that if you are smart you probably know how to do this anyway and this all is a moot point. I have never ever had a security problem with an activeX control in any version of IE, but I know what to look for. I keep my security settings where they need to be.
I think the concern here is overdone, IE 8 seems to let me know when there is an activeX concern, or haven't you guys loaded it up yet and worked with it..







