Recently there has been a fair amount of talk about bringing web applications off of the web and onto your desktop, or to put it in really simple terms: providing a bare-browser that has no UI but the site you visit. It sounds good, but I’m not convinced it’s quite workable, at least at this point. A few example of these attempts are:
The first two are somewhat generic in purpose, while FullerScreen is intended more for the task of using a web page as a presentation medium. Making it a potential replacement for something like PowerPoint.
I’m not quite sure this is really a workable model for the “average user”. Take for example the following scenario:
Say you use this as a way to make your Gmail (or Yahoo) account feel more like a client-size application. You receive an email to visit a site. You click the link and visit the site. You think you are using Firefox. In reality you’re really viewing a spoofed window. Even if remote XUL is disabled you can still do a fair job with just a bunch of cut up GIF’s. Enough to fool a casual user. Firefox has some basic countermeasures to help prevent this, such as keeping some UI.
This could be prevented if a “windowless” browser always prompts or provides some other sort of notification before connecting to an unprivileged host. Or better yet: Simply launches the real browser rather than handling untrusted url’s. That would be better and less Vista-like.
So that leaves me with the question: how should such an application behave? A true desktop application typically launches the default browser on the computer. Notable exceptions being things like Real Player, Google Earth, etc who embed a browser. How do you give a desktop like feel to an application, yet still provide the UI feedback to the user that a browser’s chrome provides?
My suggestion is simply limiting by a hostname. You have a Gmail app, you trust Gmail and nobody else. In my mind an application does 1 task and does it well. If it was intended to feel like a Gmail client, then it should do that, and that only. Want to visit that website with the monkey that sniffs his own butt? Cool, but do it in your own browser.
I’d be curious what others thought of this potential problem. I think with XULRunner looking more stable, WebKit being available to Mac developers and the merging of the web and OS, things like this are a potential problem. We are getting more and more ways to embed browsers into things (widgets, extensions, etc.). This is going to be more of an issue moving forward.
This isn’t to say I don’t like the above products (I actually really like them). I just haven’t figured out exactly how they fit into the current security model of local:safe, web:devils-playground. I don’t think they do. I think they potentially break the barrier between the web and desktop applications. We’ve all been hoping would be broken. The question is: are we ready?
The higher level question is: How do you distinguish between trusted and untrusted data when it all looks like it’s local?
7 replies on “WebApp as Desktop App Security Model?”
Robert – You raise some good questions. In WebRunner, Benjamin has some code to open external links in the default web browser. Mainly, for convenience, but it also helps security. It may not be foolproof, but works fairly well.
I do believe, as does dmose, that something more needs to be done to provide a level of trust to the user. Even if we don’t know the answers yet, at least we’re talking about it.
Mark: Discussion is critical. Too much separation, and the concept is really just a themed browser. Too little, and security is at risk. Finding that balance will take some work.
While RealWebApp currently uses a completely chromeless window, I tend to think that some more minimal chrome is likely to be useful for various reasons:
* SSL/anti-phishing UI
* back/forward for webapps that are partly AJAX and partly page-based (eg backpackit / basecamp).
* pageload status
The idea of restricting based on hostname is an interesting idea. Would that extend to disallowing (e.g.) interstitial ads by DoubleClick, or were you just thinking of restricting top-level windows?
There are also certain apps (RSS readers in particular) for which it really does make for a nice user experience to be able to open links in tabs in the same window.
In some ways, I suspect the trick is going to be figuring out the best subset of the standalone web app issue that can be solved with the appropriate balance of usability and security.
Dan Mosedale: I would even consider a “permissions.xml” file which could contain a list of allowed hostnames for the instance. So you can have multiple hosts, but only if approved.
In addition to being better from a security perspective, I think this is also a better user interface. If you click on a link to upcoming.org in Google Calendar (which is running as an application), you don’t want your app to turn into a Web browser, you want the link to open as a new tab in Firefox. I think the behavior should be the same as if the user clicked a link in iCal.
If the app is often used to open new tabs to other sites, then I would imagine users will probably want to keep the app in Firefox to begin with.
[…] be able to take my web applications out of the browser and manage them locally, and I’m not alone. Making apps more desktop-like seems to be the right way to get […]