Cox Crow

Replacing Dependencies

Meryl points out an article about a company adopting Mozilla, and comments

The hardest part about a switch campaign is reaching companies. It's costly for a company to switch its users over to a different browser. You would think not, but after I listened to a tech describe the process — it made sense. Remember IE is closely tied with the operating system and Office. A company utilizing any of these is going to have a greater challenge dumping IE.

Or, as the CERT, in its recommendation to stop using Internet Explorer, notes

Note that using a different web browser will not remove IE from a Windows system, and other programs may invoke IE, the WebBrowser ActiveX control, or the HTML rendering engine (MSHTML).

There are two issues here. First, Internet Explorer is a bunch of different components, including an HTTP user agent and an HTML rendering engine. While most people interact with it as a thing called a browser, programs can use the individual pieces of it in more specific ways. One of the programs which does so is the operating system's shell. Thus, those components are tied to the OS. This behavior is not peculiar to Windows, but is common among other operating environments. Because it is available, and because it is easy to use, numerous applications for Windows take advantage of Internet Explorer's various components. So it is difficult to disentangle the other applications you use from IE. What you can do is reduce your exposure by not using IE for general web browsing.

Which brings up the second issue. IE is a platform as much as it is an application. Some organizations, in their infinite wisdom, wrote web applications not for the web, but for Internet Explorer. Even if the application itself doesn't require IE, the developers assume that IE is the only browser available, and insist upon it, because their learned practices tend to work better in IE. So replacing IE causes their applications to break in peculiar ways.

In 1996, when Ameritech introduced their personal web pages, IE was incompetent: it couldn't upload files. And so the developers included a check in the site to limit access to Netscape Navigator. I suppose they assumed that they'd revise the application, but that never happened. Now the limit is ridiculous.

Snapfish, a good on-line photo finisher, unnecessarily used javascript: pseudo-URLs in its photo gallery application. Not because that was the only way to do what they wanted, but because they made certain assumptions about which user agents supported which functions, and so limited their tests.

The same sort of thing happens within many organizations.

What can you do to address this?

• As much as you can, write to the standards, not to the browser.
• Don't create artifical limits; degrade gracefully.

2:38:39 PM # Google It!
categories: System Administration