Browser Security

Posted by Tejus Parikh on September 23, 2008

Tejus’s Note: I originally wrote this a few weeks ago on the Appcelerant Blog.
I spend a lot of time building web apps. I find that building web applications is just easier compared to my experiences dealing with SWT and Swing. Frameworks, like Appcelerator’s, just make it even easier. Traditionally, there are just things you can’t do with a web application. You can’t interact directly with the user’s systems. You can’t (easily) install your app on the users machine. You can’t execute code from another person’s site. You have to be connected to the internet to access anything. These are pretty big restrictions, but there are a ton of interesting things that you can build with those limitations. Which is good, because these limitations are actually very sensible. You can use your web-browser to go anywhere in the world. Most of the places are going to be clean and safe, but when you happen upon one that’s not, it’s good to know that something is protecting you from it. Unfortunately, sometimes this isn’t good enough. You just need access to something, be it the hard-drive to cache resources for offline consumption or the video card for high-quality video playback. Plugins can get you close, but they can get unwieldy. Like with any problem that’s compelling to solve, there are people working on solutions. Google Gears and Yahoo Browser Plus extend your existing browser and provide some of this functionality. Adobe Air and Mozilla Prism are special browser’s built specifically to bridge the desktop and the web. In each of these cases, you explicitly authorize a new level of access. The user either has to authorize each component for a site or download something (just like a real app). However, these technologies are built on browsers and have retained sandboxes. If sandboxes protect users, great. However, if they make hard to build sensible things, it’s not so great. A great example of this is that Google Gears doesn’t let you cache external content for offline consumption. I really don’t see who is protected by this. I think the solution that gains the most traction will be the one that finds the most sensible balance between protecting the user and allowing the application developer to deliver a good solution. Remember, a real desktop app can do pretty much whatever it wants and puts the onus on the programmer to do the right thing. The world of desktop integrated web apps is much safer than the web at large. We need security models that take that into account.

Tejus Parikh

I'm a software engineer that writes occasionally about building software, software culture, and tech adjacent hobbies. If you want to get in touch, send me an email at [my_first_name]@tejusparikh.com.