The "How can I trust Firefox" post on an MSDN blog by Peter Torr made it to Slashdot, and I expect us to know very quickly how robust the .net stuff is when subjected to the Slashdot effect. It seems to hold so far, which is pretty impressive when you think about it.
In any case, it led me to wonder why I trusted Firefox more than IE, even when browsing under Windows. Of course, under Linux, it's pretty much the browser (konqueror and mozilla nonwithstanding). But I still feel safer with it under Windows. Why is that?
Well, thinking about it a bit, I'm just really scared by ActiveX controls.
Now, binary extensions are never a good idea for something used to browse the internet. A few trusted, well-known extensions such as Flash Player may be the exception (and if it weren't for the zillion sites that use those, I wouldn't trust them either!). Also, small adapters for things such as media players that are otherwise trusted are ok to me, especially when the code for those adapters is available.
But why should I have to download a binary for a bloody Google toolbar?
Most Mozilla extensions are free of binaries and run in a scripted environment, with proper sandboxing. Some do ship binaries, and I tend to dislike those; in general, they rarely work with all varieties of libc/g++/etc. that live on my system. I compile those by hand.
Scripted environments are extremely important for such kinds of extensions. At worse, you can have semi-compiled stuff (like Java applets), but expect performance to be annoyingly bad. That's because the closer to the machine you are, the harder it is for a user application to "sandbox" your code.
Another thing that's a big no-no is the automatic download of plug-ins. By all means, put a "click here to download plug-in" window. But don't even start to download anything without the user's conscent. Not even to check the signature!
But overall, the main thing that bothers me with the ActiveX extension model is an overall feeling of treating security as an annoyance, and feature delivery as the main goal.
Examples of how this is the case (note that not all of these are IE specific, but they do illustrate an overall approach to the problem that has permeated the early history of Microsoft):
- The big Word Macro fiasco. In the early days of Word Macros, I remember the company I worked for considering a way of delivering our software through Word Macros in a mostly automatic manner. The idea was to "spread the word" about the software, so to speak. The scariest part is that it worked at one point. But then, Melissa came up, and Word was hardened against macros. Well, kind of: you'd get a dialog asking you whether you really wanted to run the macros. That's a pretty useless dialog; you can't see the macros at the time you read the dialog, you don't even have their names, you don't know who wrote them, etc. As a user, how are you supposed to know what to do? So, user clicks yes, or otherwise the nice Word macros installed by the IT department won't work. Congrats, you're infected. They fixed this recently, but it took several iterations.
- All the security problems related to vbs macros in Outlook. Now, if you're running a script in such a container, I'd really restrict its operations. I wouldn't allow it to create just any ActiveX control, at least not without some registry-fu done by an installation program. And I definitely wouldn't allow an incoming mail to generate outgoing mail! But those who wrote the HTML control and the Outlook stuff just gave all scripts access to all ActiveX marked "safe for scripting", which includes nearly all of them (see below). Probably so people could write automation more easily. Wouldn't it have been better to give no access and open up on an "as-needed" basis, perhaps requiring intervention of some installer to do so?
- There is no GUI to unregister ActiveX controls if it misbehaves. It's possible to monkey with
regsvr32 /u blah.dll, but users won't usually know where the ActiveX DLL ended up. Heck, they probably don't know what the name of the DLL is! At least Firefox extensions can be uninstalled...
- The whole "safe for scripting" issue. OK, this is the silliest thing in my opinion. To make an ActiveX available to script languages, you mark it as "safe for execution" and "safe for scripting". This is done by marking it as part of two COM categories IIRC. You must, of course, sign the control. Two problems with this:
- The control is made available if, in its author's opinion, it does no harmful operations regardless of the input from the script. This is a tall order. And, keep in mind, not everybody's Donald Knuth. There are probably a lot of controls in the wild that are actually not safe for scripting at all.
- There is no support whatsoever given to programmers to even help them make the control safe for scripting. No way of specifying what types of operations the control should be restricted to; no way to restrict file operations to files selected by the user; no way to restrict access to internet connections. In general, no way to declare which Win32 APIs I want the control to restrict itself to run. What we get instead is a series of guidelines about how to write safe ActiveX. Thanks for nothing. If some script smashes my control's stack, that's it, it can inject any code it wants and all of it will work.
To be fair, I wouldn't be surprised if some XPCOM components in Firefox have similar issues. But in general, XPCOM components have to use XPCOM services if they are to be portable, and those are audited somewhat. I believe there's some security checks involved as well. In any case, there's a choke point for XUL/JavaScript extensions: they need to go through Mozilla to do anything at all. ActiveX go through Win32, with no restrictions, even if the developers of the ActiveX would prefer to have some. Instead of addressing this problem (say, by exposing OS services that are potentially dangerous through some COM interfaces, which could easily be overridden by the container), Microsoft has done the following:
- Given us confusing dialog boxes;
- Telling everybody that signed code is the key;
- When scripts managed to do some nasty things (like spam the whole planet), patch stuff on a case-by-case basis.
Not a good past history, for sure. Windows XP SP2 supposedly fixes some of those problems, but a lot of sites still run Windows 2000 and others haven't managed to get existing software to work with SP2.
How can I trust ActiveX? Code signing, without a way for developers to somehow have a fighting chance at writing safe code, is not very useful. I can't write JavaScript extensions to extend IE easily, either. And the ActiveX gets downloaded automatically, if only to check its signature. The problem, kind people, is history. The Firefox people are new, and they have been pretty serious about fixing security problems. They provide a programming model that gives the extension developers a fighting chance at insuring safety of their code. ActiveX only supplies protection before execution; afterwards, all bets are off.
OK, so I haven't refuted Peter Torr's points about Firefox itself. But I wanted to point out that if you trust the Firefox binary you installed, the programming model offered to extension authors doesn't make me too nervous. There is no such guarantee with the IE extension system.
Until .NET and its Java-inspired sandbox is ubiquitous, I think the following would really help IE become a more trustworthy browser:
- Disable automatic installation of ActiveX.
- Allow extension of the browser through JavaScript and maybe XAML. Sounds like XUL/JavaScript? Well, that's no coincidence.
- Instead of making extra services available through ActiveX controls, forcing an ActiveX lookup, only allow browsers to run well-known ActiveX (such as XMLHTTP) or controls that were installed explicitely for the browser.
- Give up on the trust model to security as the sole needed answer. Sandboxing is necessary somewhere. Programmers aren't Gods; the programming model should not expect them to be.
- Give people time. Microsoft history with respect to ActiveX security is so bad that some places will not buy anything with the word "ActiveX" in it (some departments of the Army, for instance; I experienced that first-hand at one point). Even if a new model becomes available, it will take time for people to realize it's more secure.
- Forget about legacy support. Use the fact that you're still the dominant browser platform to force third parties to use the new programming interface. If you lose dominance, it will be the worse possible time to do this, as it will annoy ISVs and prod them to move to other browsing platforms.
Credentials: I've developed quite a few ActiveX controls in my career. One was embedded in Word (and all it did was automate Word itself and display a picture, but it was a huge pain to develop--Word is far from being an ideal container). Another was embedded in IE and allowed one to sign an HTML form. The Word control didn't scare me too much because it couldn't be installed automatically and it only reacted to user events; it had no programmatic interface. The IE control needed a programmatic interface because it needed to be called through JavaScript, because HTML forms aren't as rich as Word documents. I remember being scared a lot writing the IE control, knowing that my control was marked as safe, signed, everything cool, but that I had no way to verify that it was safe. I ended up making the interface the very minimum needed so the control would remain useable. But it would have been much better to write this in script, if possible.
