Last week at both Mobile Web Megatrends and the CTIA Mobile Jam Session a major theme using the browser and mobile web technologies as a replacement for Java, BREW and native mobile applications.

Many of the developers attending both events who have been doing Java and native applications expressed frustration with the economic and technical inefficiencies of the mobile application model.  They mentioned platform fragmentation that requires hundreds of versions of an app to support even a fraction of the market, deployment and support issues, and the difficulties of marketing applications – both through the carriers and off-portal.  A number of different groups in the mobile industry, not just developers but also device manufacturers and carriers are looking to the browser to solve this problem.

There are really two separate models of web based mobile applications that are being discussed.  One is widgets, which on mobile currently means downloadable applications which look and act like traditional apps but are implemented using web technologies including JavaScript, HTML and CSS.  Widgets use and depend on web APIs exposed either by the browser or by a widget engine such as  Widsets, WebWag or Plusmo. The other model is Ajax based Rich Internet Apps (RIAs) such as Google Docs. For all the buzz about widgets I think Ajax RIAs have the greater potential because they have less friction, nothing to download making users who are adverse to downloading feel safer plus they can live in a browser tab temporarily for intuitive context switching between related tasks.

As a mobile web guy all of this is music to my ears. But but as Michael Mace pointed out at the Jam Session, two requirements need to be met before browser based technologies are capable being a general replacement for applications:

1. They need to be functional offline.  The ability to edit a document can’t depend on the availability of a network signal.
2. There needs to be access to core phone features like the phone book, calendar, camera and location.

There are at least two cross platform initiatives dedicated to solving these problem, Google’s Gears and the OMTP’s BONDI project.  There are undoubtedly others but Gears and BONDI are the most visible.

Gears is an open source project originated by and supported by Google.  It is licensed under a BSD license. Gears is currently available for Windows Mobile 5 and 6 devices as a plug-in for Internet Explorer Mobile.  Opera has announced that future releases of Opera Mobile 9.5 will include Gears. Android will also include Gears but probably not in the initial release.

At this point Gears does not include everything an application developer might want. There is no access to PIM data or the phone camera for example.  What Gears does provide on mobile is online storage and data synchronization, a geolocation API  and asynchronous background proceesing. Google has espressed commitment to aligning the Gears APIs with the evolving W3C HTML 5 and WebAPI standards for offline data, synchronization and location.

Gears security uses a same-origin and permission based security model. Same-origin means that a script can only access an online resource via its own domain, protocol and port, in other words cross-site scripting is blocked.  At the device level the plug-in prompts the user when an application using the Gears API attempts to  access local resources.  The user can grant or deny access. Gears can persistently store the permissions granted to a particular domain and API function so that the user is not prompted each time.  For access to native functions Gears is ultimately limited by the device’s own security features.

Bondi is named after the famous Australian surfing beach and aims to provide great, but safe surfing. It defines interfaces and API’s that allow web based application access to device features and user data in a standard, controlled and secure manner. BONDI is a draft proposal of the Open Mobile Terminal Platform (OMTP), a non-profit mobile industry group founded by eight mobile operators. OMTP membership currently consists of over 35 companies  including carriers, device and chip manufacturers, developers and content publishers.  The OMTP’s goal is drive standardization and inter-interoperability accross mobile platforms.  OMTP hopes that BONDI  will find it’s way into handsets sometime next year.

The project’s scope is extensive and covers just about anything anyone could want in terms of access to phone features. BONDI has or intends to define JavaScript API‘s for access to location; call log; camera and photo gallery; personal information including phone book, tasks and calendar; application invocation, persistent storage, making phone calls; messaging and message management; phone status such as signal strength and battery level as well as providing a set of standardized rich user interface controls including as alerts and resizable windows.  The OMTP recently joined the W3C to champion the inclusion of BONDI in future mobile web standards.

As you would expect from an initiative with operator input, there is a strong emphasis on security. BONDI defines an elaborate structure  of policies and access controls for granting web pages and widgets access to specific functionality based on certificates and certifications.  This is a big change for web based applications.  It goes way beyond the basic level of security provided by HTTPS secure web sites.  As I read the BONDI draft documents, it looks like each web page containing JavaScript that accesses handset features through BONDI will need to be signed with a special BONDI certificate. This certificate which will only be granted after the web service or widget has been  tested and verified for security and functionality by an independent testing lab.  This sounds a lot like the process that applications need to go through to receive certifications like Java Verified and Symbian Signed.

In summary, Gears and BONDI have similar goals but are quite different in both scope and security.

Gears is shipping today with limited functionality, BONDI is very comprehensive in scope but availability appears to be many months away.  I suspect that Gears will continue to gain more functionality and that BONDI will initially launch with a subset of its proposed APIs.

A more fundamental difference is in the way the two projects approach security.  Gears extends to mobile the traditional web and PC model: inform the user of risks and trust him or her to act in their self interest.  BONDI takes the paternalistic approach that users can’t be trusted to make wise choices. The platform itself must enforce security through verification and certification.

Security is always a trade off betwen user empowerment and safety.  The BONDI approach undeniably does a better job of protecting both user data and network security.  But it also creates more barriers to entry for developers and vendors, tending to reduce innovation.  An open approach such as Gears’ enables greater innovation with some increase in  risks for users and networks.  There is a place for both approaches.  Carriers and Enterprise IT will demand a secure verified application environment for the devices they sell and support. Open source developers, power users and new hardware makers without access to carrier distribution channels will appreciate the opportunities and low barriers to entry of the more open model.  I support both. Together they will help to define a new era of web based mobile applications.

Related Posts:
CTIA: Mobile Jam Session
Content is King on Mobile Too
Google Gears Opens Up Mobile LBS
Google I/O Wrapup