A few months ago, I posted about a concept called Site Specific Browsers (SSB). I didn’t invent the name or the concept, but I thought it was a great idea. An SSB is an application with an embedded browser designed to work exclusively with a single web application. It’s doesn’t have the menus, toolbars and accoutrement’s of a normal web browser. Some people have called it a “distraction free browser” because none of the typical browser chrome is used.
The recent talk/hype over desktop/web integration has rekindled my interest in creating a project to test SSB ideas. As is usually the case, I would not be the first:
- GMail in a WebKit application: Nice application in separate process.
- GMail in a XULRunner application: Basic framework running in separate process.
- GMail in a XULRunner application: Small application with some menus and toolbars in a separate process.
- GMail and GCal using bookmarks in Camino/Firefox: Simple way to open a new window without chrome. Not in a separate process.
- GCal in a WebKit application: Application in separate process.
Yeah, Google webapps are a popular choice for an SSB.
Looking at what has already been done and discussions about desktop/webapp integration, I am suggesting the following roadmap for SSB experimentation:
- Separate process: When the webapp goes down or locks up, I don’t want anything else affected. Thankfully, Firefox does have session restore, but that is beside the point. When I open many tabs and have several webapps running in a browser, things get slow and unstable after a day or two.
- Minimal UI: A generic browser UI is not needed for webapps. If any UI is present, make it specific to the webapp I am using.
- Basic desktop integration: Create shortcuts to start the webapp, add ability to show specialized icons in the tray or dock and ability to display notifications.
- Platform with extensions: I don’t want to download a full browser runtime for each webapp. I do want to be able to add some custom code/features that are not directly supported in the webapp. I should be able to install one runtime and then get packages or extensions for each webapp. Think Firefox extensions or Greasemonkey scripts. These extensions should be able to tweak the SSB UI as well.
- Open external links in real browser: If I click a link in the webapp that opens a new site, don’t change my webapp browser window. Open all external links in my default/real browser.
XULRunner’s stable base, feature set and cross platform nature make it a good foundation to build an SSB. In fact, I’d just start with the the WebRunner prototype created by Benjamin Smedberg. Then, I’d turn on the Extension Manager support in XULRunner. Then, I’d create some extensions to “install” or “enhance” webapps. Then, I’d add some patches to add better desktop integration (I’m hoping the patches land for Gecko 1.9). Then, … well you tell me! How about offline mode? What else?
Here is a simple example of a WebRunner-based SSB. It only begins to cover the points on the roadmap, but it is a start. The application is designed to take a -uri parameter on the commandline. The installer will setup desktop shortcuts to launch webrunner.exe with specific URIs for Google web apps. The UI is minimal, just a simple statusbar to show load progress.
Install (Windows-only): webrunner-setup-0.2.exe
Source: webrunner-src-0.2.zip
It seems like many of these features are common across many webapps- why not integrate them directly into the browser, and allow either sites or users to trigger them through the browser? It seems like having one browser for site X, another for site Y, another for site Z, etc., all of them sharing 95% of the same features, all useful for only one site, all having to be updated for new features/security fixes, etc., is a suboptimal solution to the problem. But maybe I’m missing something obvious.
Do you know Mozilla Amazon Browser already? Seems like a site specific application for me. I tried it a few times, but using my standard browser is still more convenient.
“Platform with extensions”
How do you see this one being delivered? As a separate-from-Firefox platform “WebRunner”? Or utilizing XULRunner with Firefox 3?
If it is the last one, the information on the Firefox3/Gecko Feature List seems to throw a little cold water on the prospect. “Firefox on XULRunner (and shipping XULRunner platform)” is only given a P3 priority, and the comments read:
“In Progress; we can ship without it”
– http://wiki.mozilla.org/Firefox3/Gecko_Feature_List
Doesn’t seem like it’s too high up on the radar.
I fail to see the point in having another platform for this. XULRunner is the platform of choice for standalone applications once the deployment/installation issues are sorted out. So IMO this makes sense as a XULRunner application generator that would generate such an application from a few parameters like starting page, sites the application should be limited to and maybe some custom XUL/JavaScript code. Unless of course a WebRunner extension is supposed to have lower privileges than a XULRunner application but that might be difficult given your requirements.
Luis & Abdulkadir – The browser will likely stay the predominant way people use webapps, I agree. There are advantages / disadvantages in both approaches. A SSB is just an alternative.
enefekt – I am not suggesting that an SSB be tied to any XULRunner runtime shipped with Firefox.
Wladimir – WebRunner is a XULRunner application with a few extra parameters that allow it to wrap different webapps. This is not a new platform.
I would really like users to be able to right click on a bookmark and turn it into an application (or maybe an option in the File menu for the current site). Firefox then dumps it on their desktop, and when the user opens it they get a SSB that has its own icon, place in alt/command-tab, in the taskbar/dock, etc.
“I am not suggesting that an SSB be tied to any XULRunner runtime shipped with Firefox”
Assuming multiple SSBs share a single runtime, then part of this WebRunner endeavor would be creating a decent install/update experience of the WebRunner runtime. This would be a cool (though difficult) effort, if Mozilla doesn’t do this with Firefox 3.
But, IF Firefox 3 did end up coming with XULRunner, then why not use it? If a perfectly good, recent, “official” XULRunner runtime exists already, why install another one?
I dare say that this is a champion concept. The ideal incarnation, for me, would be the means to custom-configure an existing platform such as Firefox on a per-site basis. Specifically, a bit of code can be placed on the site indicating that it supports a custom interface. Firefox then prompts the user whether they would like to use the custom interface and if so, it is downloaded, installed and used. This preference is then remembered.
This is a neat solution to a number of problems.
One, it’s convenient for users.
Two, users retain control over their experience.
Three, an enhanced experience can be delivered through the SSB; however, users with other browsers or environments may still access the app.
Four, the web app code can still be standards-compliant, globally-renderable code… but specific, cleanly degrading hooks can be added for the SSB to do things in a more efficient manner.
Five, because the custom interface can be tied to a domain, a shortcut can simply be created by way of a link to that URI. Simple!
I agree that XULRunner seems a promising basis.
-Rob.
I am reasonably new to programing web application and am still feeling my way, so please for give me if I have the concept wrong. I think that in my case SSB’s would be a god send! I write applications that I deploy on customers systems and then they use them with what ever browser they have installed. Then they upgrade the browser or it upgrades automatically, hay presto my applications no longer runs.
The ability to install a scaled down version of say Firefox, ( no need fo toolbars etc… ) when installing my web app and point the web app to that browser to run in would mean my web app would run first time ever time. My customer would be much happier to. Bring it on, the sooner the better.
Right now, if you use a separate process, you also get a separate cache/history store, which is probably not desirable. For Moz2 we will hopefully have cross-process shared cache and history, but in the meantime I think we should focus on making this work within the Firefox process. We could do this with an extension now, I’d bet. Link targeting is still the hard part… how do you decide which links are “external”? I’ve written up a proposal for a link rel=”external” that would allow webapps to specify that explicitly, but nobody has implemented that yet.
Neat.
I’ve since written an Apollo-based Gmail.app, and I have to say that that was roughly 5x easier to get running than the equivalent XULRunner-based Gmail.app.
Have you guys ever thought about whether or not SSBs (I started to call them minibrowsers, but site-specific minibrowser might be more apropos) have any place in reducing security risks for knowledgable users?
I don’t think it solves the end-user phishing / trusted path problem, but for power users, I can imagine it’s a lot easier to trust a downloaded SSB which has almost no chrome and no extensions, and is launched separately like a desktop application.
If each SSB has its own cookiespace, then CSRF-style attacks become more difficult.
Ka-Ping Yee has done some work in making voting more secure (http://zesty.ca/voting/), and I wonder if SSBs would at least be a step in a more secure direction for power users.
At the very least, SSBs ought to make it easier to prototype trusted path browsers…
I’ll probably be at the Mtn View dev day if you’d like to chat more about this.
~L