Site Specific browsers
The launch of Mozilla Prism has many people thinking about the possibilities of Site-Specific browsers. With many applications such as GMail and Google Documents being packaged up as hosted Web applications today, a site specific browser provides a quck and easy means of making a network application look just like a local applications. User Interface components designed to support browsing such as the address bar, bookmarks and such are unnecessary clutter and the forward/back buttons a positive hazzard when using a Web application.
Site specific browsers are also a useful security tool, particularly when setting up a browser environment for use by a three year old girl who wants to visit the 'Dora the Explorer' game on the Web. A site specific browser allows an account to be created that can access precisely the sites that are age appropriate. This is as much a usability issue as a security issue, avoiding the situation where the mouse clicks on the wrong thing causing another site to load, ruining the game.
Making the browser site-specific is certainly one means of achieving the 'secure browsing mode' that many banks have been asking for, But users have enough trouble downloading an installing one browser. How can they be expected to download, install and maintain a different site specific browser for each bank and brokerage they might use (I have two of each plus a 401K retirement fund and a life assurance policy making six in all).
A recent paper by D.K. Smetters and Paul Stewart suggests a neat solution to the problem. In their scheme, a user is told to access security sensitive sites from a 'secure launchbar' that causes a site specific browser to be launched in a separate process. Instead of having to have a different site-specific application for each bank, all we need is a site-specific secure bookmark.
Clearly, for such a scheme to be trustworthy, the secure bookmarks must be limited to trustworthy sites. Smetters and Stewart suggest various means of achieving this, but I am sure nobody will be surprised to learn that Exetended Validation certificates with embedded subject logos (aka Secure Internet Letterhead) would be my choice.
To complete such a scheme, agreement would be necessary on a standard set of capabilities for 'secure-site-specific' browsers. Traditional W3C specifications describe the features that MUST be supported. This specification would also need to specify which features MUST NOT be specified. Or at least provide the launch bar application with a means of specifying the features to be activated in the site-specific browser. Cross-site scripting attacks have much less power when the user is accessing a site with plug-in extensions disabled and no ability to follow links that lead off-site.
