Everyone should use Site Specific Browsers
You have probably already heard about Mozilla Prism, an "XULRunner based browser that hosts web applications without the normal web browser user interface." You might have also heard about Fluid, the same idea using Webkit on OSX. There's a lot of FUD and confusion on the web about SSBs, and I'm here to tell you that it's all wrong. They are not a competitor to runtimes like AIR and they are not useless either. They are not the same as a chromeless browser window, and yes, EVERYONE should use them. Here's why:
The only thing no one has mentioned in regards to SSBs is security. Security is a huge pain with browsers; when you visit a site, all of your browser's cookies are available for that site to access. People have their information stolen all the time because they browse the web while they have their bank account, e-mail, or shopping cart open in another window or tab. The plain and simple truth is, you shouldn't be browsing the web with a bunch of windows or tabs open while you are logged in to a site which has access to your essential information, because if it can access that information, ANY OTHER SITE can too.
This is why security experts recommend that you use a separate browser to access critical online applications, or that you close out your browser completely and access a critical app on its own, so that you don't risk allowing other sites to access any of your cookies.
SSBs make the whole security issue much simpler. Something that you'll notice after moments of testing an SSB like Prism with say, Gmail, is that even though you are logged into Gmail with Prism, if you open up Firefox and browse to Gmail, you are not logged in there. Whatever cookie information is stored by an SSB, like the one I use to access Gmail, is completely confined to that SSB, and safe from any web browsing you do in your normal browser.
This is security gold. Sure, there are other benefits, such as I never have to worry about a memory-heavy webapp like Gmail crashing my entire browsing session (which has happened many, many times) and an SSB gets its own Javascript thread, meaning you won't lose performance nearly as much as when you run it in a browser with other tabs open (or when you get hit by a Flash popup, which can be incredibly CPU intensive). But those benefits pale in comparison to the security that is provided by the use of SSBs.
This is why all the FUD and confusion needs to stop. If you use webmail, or you often log into sites that use your financial information, like your bank account provider, or your credit card account, or sites like Ebay, Paypal and Amazon, then you need to set up an SSB for those. It may seem like a bit more work, but it's worth preventing the risk of losing your financial information. Plus, at the enterprise level, SSBs are even more useful; for Intranet applications that have access to sensitive information which must stay within the Intranet, it's far better to set up an SSB for every employee to use than to just trust them to maintain safe browsing practices. If I had a company of my own, I would set everyone up with SSBs. I wouldn't have it any other way.
I'm hoping someone will come up with an SSB option for Linux soon; I don't care if it's Mozilla or someone else. They're far too useful to do without. Edit: Hey, Prism is available for Windows, OSX and Linux.
I must have missed the OS X installer yesterday when I was looking at Prism. I really like the idea of Fluid, but alas, it's Leopard-only, and I'm still on Tiger (with no good enough reason to upgrade yet).
Thanks for this eye-opening article. I read about site specific browsers but wondered why I should use something like this when I have my browser already opened.
Your explenation was very insightful and I think I will download and use Fluid tomorrow.
Greetings
I suppose this is irrelevant now, but I guess a few weeks ago this would have stopped Facebook's beacon from publishing your 3rd party website actions.
Hi Christian,
Sadly, I'm reading this article too late, and have had my business attacked while on holiday.
Someone hacked my GMail account, then stole my domain name and all its traffic.
I've published a blog post about it, and linked through my name.
Hope you have a great xmas!
Why would you think something like that?
Henning: I don't think, I know. Go study Internet security.
Well, you're wrong. The mechanisms behind cookie stealing hacks are much more complicated than that.
You're not citing any sources, hiding behind weasel words like "security experts recommend" and for pointing out an inaccuracy you patronize me with "go study Internet security"?
Henning: I hate getting into technical lectures on this blog, because I don't like to rewrite all the information that is already available on the Internet. But since you accused me of being a weasel about it, I'm going to get pedantic just for you.
I went to a talk put on by security experts who provide security services for websites and intranets of companies of all sizes. They said that whenever they need to access important online services such as e-mail accounts or financial accounts, they use a separate browser than their usual browser for websurfing with that site being the only one open in the session. They also said that some security experts go so far as to load a virtual machine and then destroy it to access these services. The reason is that if someone knows the cookie identifiers or POST identifiers that a service uses, they know how to retrieve those cookies from your browser or POST data through your browser session and hack your account.
It's really not that complicated. The point is the same. I just didn't necessarily say it the way you preferred. Is that better for you?
Henning: PS, you are correct, what I said was literally wrong. What I should have said was that if you are logged into one site in one tab, and you visit a hacker's site in another tab, they can do POST requests to mess with your account that will take advantage of the fact that your cookie and session information is maintained in your browser. David's comment is a perfect example of that. Sorry for the short comment that I posted above.
You need to update your knowledge of how cookies work. You are spewing a lot of misinformation and FUD yourself.
Cookies are specific to a domain. Period.
One more thing,
Your inability to admit you are wrong is a big roadblock to your success.
Mike P: Yes, I am very unsuccessful
I would agree with several of the other posters here. Cross-domain cookie access is generally not possible. (If you still think it is, a specific reference would be welcome, rather than a vague reference to "security experts.") The primary attack on this is host name spoofing, something mostly preventable by using SSL/TLS and signed certs. A SSB that does not do so is equally vulnerable to such attacks on your non-transient cookies. (And transient cookies too if the SSB is running in a shared address space with the other browser instances.)
But once you start going down this road, cookies are the least of your problems. Even running in a SSB in a VM will not protect you from typing in confidential information to an apparently real, but actually bogus, web site.
I will also add that the cross-domain limitation applies to first-party cookies. Third-party cookies are a different issue and I could imagine some stupid scenarios where confidential information could leak out due to use of third-party cookies. But such a poorly designed site would probably continue to have problems even with SSBs.
Again, to have a useful discussion, one needs to discuss specific cases.
To be constructive, here is a specific form of cross-site scripting that might be mitigated by SSB:
http://www.webappsec.org/projects/articles/071105.shtml
The guys complaining that other sites can't really access the cookies from important site X are unfortunately misguided. They don't need to - they can use cross-site request forgery (XSRF) to submit requests to site X without showing the user that he's doing anything on that site. As long as the user is logged in on to that site, he is vulnerable. Lots of sites are vulnerable to XSRF, it's going to be the next big thing in security issues, and since the days of XMLHttpRequests (AJAX=-technology) it's as easy if not easier to do bad things with XSRF than with XSS. So yes, site-specific browsers are a great security improvement - definitely use them for all transactional web applications!