Submitted by “Conspicuously absent from Microsoft’s annual MIX conference here was any discussion by the software giant about whether it plans to change the way ActiveX will run in Internet Explorer 8 . . . Some security experts, like Will Dormann, a vulnerability analyst at the Carnegie Mellon Software Engineering Institute CERT/CC, are calling for ActiveX to be disabled from running by default in IE 8.”
… 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 ^aEURoetrusted CAs for ActiveX^aEUR and only add its own certificate to the list initially^aEUR”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^aEUR”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.
That seems like a pretty sensible solution. Agree, thanks.
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.
What makes plugins secure from the same problems that plagued ActiveX? The netscape plugin API is the same as ActiveX in that you run native code within the browser process. IE supported the NSApi plugin model too, as far as I know, as simply another ActiveX control. The security problems did not start until after Netscape had shot itself in the foot, so no one bothered to write malicious plugins against NS. What stops the same problem from happening with Mozilla plugins?
The problem is in the sandboxing. Sure, technically the JVM on IE is inside a COM wrapper, but it has that extra layer of abstraction that is locked down by design. There is a difference between that, and wrapping some MFC bits in a COM wrapper, as MFC was never really designed to be run in a least priviledged environment. IMO the only reason they even went down that route in the first place was because that was pretty much in the middle of the period where MS was in the pissing contest with Sun. Doing applets with visual J++ would have been a much better idea, but that was pretty much nipped in the bud.
Feel free to educate me if I have this stuff wrong, during the height of COM/COM+ I was writing J2EE apps, so while I am familiar with it, I am far from an expert. I do know that what we have now with .net browser wise beats the pants off of what was availble back then though.
I was in middle school back then, so it’s not like I lived through it
.
The JVM would have been the best thing at that time, but even the MSJVM was not optimized enough to run as quickly as would be wanted in a browser. These days, though, we can tolerate comparative pigs like JavaScript and Flash, so the JVM and CLR are good enough.
Needless to say, the JVM would have probably been the preferred API for browser-based apps instead of ActiveX if Sun hadn’t started a lawsuit. I won’t argue about the actual merits of the case because I haven’t studied it at all, but Sun definitely did kill client-side Java’s chances of success when they sued the biggest external implementor of their technology.
Edited 2008-03-09 00:42 UTC
Basically what happened is that Sun was the first ones out the door with the idea of a browser applet. MS didn’t have anything like that, and being in the height of its “embrace and extend” days, they did their own implementation of java with propriatary incompatible extensions.
Now, an arguement can be made that visual J++ was the best java IDE for a really long time, and the MS JVM was hands down the fastest, and even that alot of the extensions were really needed. The problem was that MS has always had a vested interest in windows being part of the stack, and sun has had a vested interest in keeping java a cross platform technology.
Lawsuites raged for a long time, and Sun rightfully won. This was a really good thing for the microsoft world though, because .Net was Microsofts plan B. It was even good for the java world, because Sun has actually finally started addressing users needs, now that they actually have something in the way of competition.
Java has been king of enterprise development for years now, partially due to the fact that pre .net, ms was missing some vital pieces in the puzzle (ASP classic front end, and everything going through transaction server? don’t make me laugh). Nowadays, Sun is wetting its pants about .net, because they know if MS ever takes the plunge and takes it cross platform, they are toast. They also know that there is no way they can keep up with MS in pure developer power, which is what the whole open sourcing of java was about. The fundamental problem though is the Java Community Process, which makes MS look downright agile when it comes to getting things done. Not only that, but .net is competitive at both the desktop, and the enterprise level. Sun has let the desktop side go for so long, they are only just reaching the point of acceptability now, just in time for MS to up the bar with the 3.5 stuff like WPF.
Anyways, sorry for the long post, but this has been my world for a very long time, and I have alot to say about it :-). I switched sides when .net 2.0 came out, and I really havn’t looked back. I find that the windows user community leaves alot to be desired, but being developer on MS platforms nowadays is an absolute joy. I have also sort of developed a man-crush on ScottGu…
DevDiv is one of the more successful divisions of Microsoft because its customers are more technical and less emotional. It’s similar for things like Server and SQL. What people want can be distilled to a set of features, APIs, and performance goals.
There’s also a cultural thing… Microsoft is always at its best when there’s a strong competitor in the field. That’s part of why I’m excited about all this good stuff coming out of Apple.
I’m pretty sure that .NET started after the MSJVM was killed.
How incompatible was our JVM at the time? (I was learning C then, so I never did any Java). As I understood it, people like Anders Hejlsberg were working on a set of classes to access Windows drawing and other APIs directly and they replaced JNI with J/Direct (maybe I’ve got the names mixed up) which is very similar even in name to P/Invoke.
But it looks like the cross platform stuff was also implemented with reasonable compatibility. I don’t remember any applets not working in the MSJVM, but I can’t say for sure that they did work in Sun’s JVM.
So, yeah, it would have made two sets of features that developers would have had to choose between. Thankfully Sun rescued everyone from that difficult choice by assuming that Devs would be too dumb to make their programs cross-platform if they didn’t want to be bound to Win32. They felt that people would just write apps and assume they’d work on all of the Javas out there without doing any testing. I feel that even without any extensions to the underlying platforms, different implementations of J2EE are incompatible enough that issues need to be found through testing.
I don’t want to give the wrong impression, though. I like Sun’s OS group and I think Java was a great gift to the world. But I think their management was too much like Durusau’s Russian Peasant when McNealy was around:
http://www.durusau.net/publications/russianpeasant.pdf
Incompatible enough. I *still* have several users that I can’t move off of Windows because they’ve convinced their supervisor that they *need* a certain online maps application which requires “Java”. And it will not run in anything other than *Microsoft’s* “Java”. It’s a long-standing known issue, and all the provider’s technical support department has to say is “All you have to do is download the MSJava plugin. What’s the big deal?”.
Sun had a choice. They could go to court… or sit back while MS intentionally corrupted and polluted Java. Microsoft’s actions are indefensible, and we are still living with the consequences today.
Edited 2008-03-09 18:34 UTC
see my massive rambling response here http://osnews.com/thread?304010
Like I say there, it is possible to make an argument that their actions were done in good faith. The extensions they made to the platform were obviously good, since pretty much everyone used them. If they were just random junk thrown in to muddy the standard, noone would have bothered.
Where discussions like this tend to break down is that you, as someone who doesn’t use their products, only really feel the outward effects of their descisions (In this case, the fact that an incompatible JVM means platform lock in). Someone using Microsoft products feels something quite different (extensions that made life easier). The resulting discussion ends up working at cross purposes, you assume that these descisions were made only to screw with the rest of the world, people who work on the platform assume they were made solely for their benefit.
IMHO in this specific situation, it started out as something done in good faith, without thought about the consiquences. Sun flipped out, and what ended up happening was a great big F-U coming back from MS, which ended up killing the standard.
We have talked before about whether or not MS is still a den of rampant Evility. While some of their reputation is well earned (like what they did to Be for example), I think that most of that came from the lawyer/marketing side of the company. I think what happened from the technical side was more “unintentional evility”, and that this is what is changing. The technical side of things is showing a greater awareness of the rest of the world and taking them more into consideration, and the lawyer side of things is getting repeatedly spanked down by various regulatory powers.
Wow. You think that after all these years, a part of the 900lb gorilla’s mind has finally noticed that he’s a 900lb gorilla? Too bad about all those people he accidentally stepped on and crushed to death before. He’ll have to try to do better. And that’s the “good” side of his nature; The one not in control. You can bet that the Id, the legal/administrative side of the company, and the entity actually in control, is brainstorming to figure out how to break out of any cage erected around them.
I’m just waiting for the part where he gets to the roof of the Empire State Building. Though I suspect that in this case it might end up being the top of the Eiffel Tower.
Edited 2008-03-09 20:29 UTC
A big part of the whole issue was the politics between the two companies. People were pretty much ignoring the Sun JVM, which caused alot of problems on several levels. Ignoring the politics though, the valid technical issues were the same as what MS did with JScript.
A syntactical extension like document.all is arguably just a helpful shortcut, and document.getElementById() still exists in JScript, so its not like they are forcing you to use it or anything. The problem is that because it is a shortcut that doesn’t exist on other platforms, and back in the day noone really thought twice about non IE browsers, there were alot of people who didn’t make the effort to learn that it introduced an incompatibility. Because of that, there were alot of scripts written that just plain didn’t work on anything but IE.
Same deal with the MS JVM. You can make a good case that the extensions were done in good faith, and filled some much needed gaps in the existing JVM. The problem was that since they made life easier, and since the MS JVM was on close to 100% of the browsers out there, people used those extensions. Since the syntax of MS Java was a superset of Sun Java, a standards compliant applet would work in the MS JVM, but an applet using MS syntax wouldn’t work in the Sun one.
It was really a combination of things that killed the applet. Sun seemed to decide at one point that anything not J2EE didn’t diserve any love, and GUI java stuff was downright awful for a long time. Add on to the fact that MS stopped updating the MS JVM as soon as the lawsuites started flying, so as the years went by, even when the JVM got many much needed syntactical and performance improvements, the state of Java applets were more or less frozen in time. When flash showed up, they didn’t need to compete with current Java, they had to compete with java of the early 90s, and as such they pretty much blew past it. The last straw was when sun finally won and MS uninstalled their JVM through a browser update, that broke compatibility with the vast majority of applets that still existed.
You can easily say MS acted in good faith through the whole thing, but I really think there was rivalry going on on both sides of the fence. When .net first came out, one of the first things MS did was pay some guys to rewrite the J2EE reference app that Sun published to show best practices (petshop), and did it with a fraction of the code and large gains in performance. You also have J# as a productized language from day one. They billed it as an easy migration path, but IMHO it was more a “We can still do Java better then Sun” type statement.
You are right that Sun has put out alot of good technology. The big problem when it comes to Java is that they are way too ivory tower in their design patterns. In almost every case that I can think of, following Suns best practices is only a good idea if you are building the most massive of projects. For anything smaller, you don’t want to do an n-tier model with all the trimmings, and you will end up wasting time writing mountains of code that are not nessicary. I find the MS “Provider abstraction layers for everything” approach far more enjoyable to work with. If you use default providers, you can work at a very high level and get things done very quickly, but if you ever need to, you can make your own lower level bits and plug them into the pipeline very easily.
To use MS lingo, .Net handles Mort, Elvis, and Einstein all very well. Java only does Elvis and Einstein. If we are using the analogy to pigeonhole developers, sure, thats not really a bad thing (we all run accross Morts from time to time). But if we take the analogy as different development styles, it comes up alot in a project lifecycle when something needs to be done fast in a basic way, and spending time having to learn internals for every little thing just bogs down the process.
Microsoft was in a pissing contest with Sun, but the technology behind ActiveX can be considered apart from that.
As far as I can tell, ActiveX controls are simply webified OLE controls.
OLE2 came out around 1994, and with it the ability to do “in-place” activation of OLE objects (both .exe and .dll OLE objects).
In 1996, OLE Controls were introduced, which were essentially in-place OLE objects that implemented COM interfaces specific to “control” functionality. These could be placed on Word forms, Excel sheets, etc. Also, VB4 was released which replaced the old VBX components with OCX OLE Controls (and the 3rd-party OCX market thrived, becoming the largest and most successful component market in history up to that time).
After that, ActiveX Controls were introduced, which were OLE Controls that implemented COM interfaces specific to interacting with web pages and web browsers. And IE was redone to simply be an ActiveX container app, along with the shdocvw.dll and mshtml.dll ActiveX controls. (IIRC, IE.exe hosts shdocvw.dll as an ActiveX control, which in turn hosts mshtml.dll as an ActiveX control to render HTML, which in turn hosts ActiveX controls that may be needed by a web page (e.g. the Flash Shockwave control, WMP, etc, or custom .dll controls). And the cool thing was that any OLE control container app could also host mshtml.dll as an ActiveX control and get the same functionality as IE.)
Note that the above is from my memory, and could be incorrect. If there is anyone that is more familiar with the details, feel free to correct me.
As I said earlier, the security problems had to do with malware ActiveX controls getting installed via the ActiveX download-n-install mechanism (either through bugs or inducing the user to OK the install). Oh, another big security problem was due to bugs in the ActiveX controls themselves (buffer overflows), but those could happen with any .dll plugin architecture, and do (didn’t Apple just recently release security updates for their Quicktime plugins, for both their Firefox Quicktime plugin and their IE Quicktime ActiveX control?).
Edited 2008-03-09 03:55 UTC
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..