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.
- 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.
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.
- 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.