<b>Is the browser becoming the new operating system? We have an exclusive report from eWeek.</b> <i>By Jim Rapoza</i>

Yours is a typical modern company.

You have sales and customer management systems, advanced project management tools, extensive network and system security infrastructures, collaboration tools, and a heavily customized enterprise content management system.

What's not so typical now--but will be in the near future--is that none of these applications is run in-house. All of these core applications are delivered over the Web in a SAAS (software-as-a-service) model. As such, the applications are accessed via a Web browser that is basically acting as the operating system. There's nothing wrong with that. Right? Right?!

The idea of the browser as the operating system has been around since the early days of the Web. In fact, it is generally accepted that Microsoft went after Netscape so hard because it feared that the Netscape browser would become more important than the operating system it ran on.

That fear may have been unfounded at the time, but we are much closer now to being able to access everything--from e-mail to office applications to image editing to essential enterprise business applications--from the confines of the humble Web browser.

This means that businesses should start to take a much closer look at the Web browsers on which they standardize, especially in the areas of compatibility, adaptability and security.

At least for now, a business can choose the current version of any major Web browser and feel fairly confident that it will work with most SAAS and Web applications. This is due in large part to the popularity of AJAX (Asynchronous JavaScript and XML), which has let Web developers build interactive, rich GUIs for applications that work across a broad set of Web browsers.

But that doesn't mean there aren't potential gotchas for a company looking to essentially move to the browser as its operating system.

For example, if your SAAS provider isn't keeping up with newer development technologies, you could be stuck with an application that works only on, say, Internet Explorer--or, even worse, only on older versions of IE. And, as we continue to move into the next generation of Web applications, Web apps may be delivered not via a browser but as rich Internet applications. IT organizations need to be prepared to make such a move.

Finally--and most importantly--when the browser is the OS running your company's mission-critical apps, is security the responsibility of the application developer or the browser maker, or some combination of the two?

What price flexibility?

One of the greatest things about using an online application is the flexibility it offers users, who can access a core business application from their Mac laptop, their office Windows system and a friend's Linux system.

And things have never been better when it comes to choice. At eWEEK Labs, we test SAAS applications on a regular basis, and it is very rare to run across one that doesn't work with all current-generation Web browsers--whether it is IE, Firefox, Opera or Safari.

In fact, at this time, there really isn't an overwhelming need for a company to standardize on a Web browser. Users are essentially free to use whatever browser they choose, with minimal impact on support.

But attention has been growing in recent months on an area where all browsers may not be created equal: security. There's seldom a week that passes when a security hole isn't found in a major Web browser. Further, none of the major Web browsers has been immune to security problems in recent months. (click here to read about PayPal's plans to ban unsafe browsers)

However, it's important to note that most browser vulnerabilities are exploited from a Web application and not from the browser itself. In most cases, a bad guy has to trick a user into going to a site that has code that can leverage a hole in a browser.

This means that if a SAAS application is clean and its users never visit any other sites, even the most hole-ridden browser would be fine. Of course, this model doesn't work in the real world, where most people use their browsers to visit dozens of different sites every day.

As a result, security responsibility does lie with both the application vendors and the browser makers.

Yes, browser makers could lock down their browsers to a very high degree, but this would severely limit a browser as in many ways the whole purpose of the Web is about the free flow of information between sites and applications, such as in a mashup or SOA (service-oriented architecture) model. Therefore, the choice of browser as an OS depends more on how quickly a browser maker responds to security problems and if they add features that aid in identifying potential problem Web sites. (click here to read about a project to build a security browser)

For the most part, SAAS vendors don't have to focus on specific browser issues. In general, following good security practices on the development side and closely checking for and fixing bugs will protect their applications from problems no matter what browser their customers use.

In fact, the biggest problem these vendors face is outside of their control--namely, phishing sites that look like their applications but are designed to steal customer data and infect visitors with malware. The use of browsers or of plug-ins and extensions that protect against malware and phishing sites can help but will not totally protect against this problem.

Unfortunately for businesses looking to evaluate the security of SAAS applications, most SAAS vendors work very hard to keep any past or current security problems as secret as possible. Just because you haven't heard of a security hole in a SAAS application doesn't mean there hasn't been one. In fact, odds are that most SAAS apps have had security issues. Making sure the terms of service protect your business against any potential leaks or downtime is key for any SAAS evaluation. And the general community reputation of a SAAS vendor is a good clue as to how it handles bugs and security issues.

>>> More Architecture Articles          >>> More By Jim Rapoza