The significance of Google Gears on mobile devices – part two

In a previous post, I highlighted the significance of Google Gears on mobile devices. Google gears launches on Mobile – The hour is later than you think ...

This follow on post builds on that discussion and is based primarily from online conversation with Morten Hjerde .

The Gears announcement is a market accelerator. Today, the browser vendors badly need to differentiate themselves. With webkit becoming significant over the last year(Apple, Google and Nokia all going for Web kit), pure browser companies like Openwave and even Opera need a differentiator.

One accelerator is standards. Standards are good and standards are coming in this space with HTML 5. However, HTML 5 is a way off(2012)

So, we see the browser market to be driven by some key developments

a) Device manufacturers like Nokia have had success with webkit

b) Apple/iPhone also has done the same

c) Operators are watching this space and also may experiment with initiatives

d) Traditional browser vendors are looking to differentiate

It is in this backdrop that we have to look at the Google Gears announcement. At the moment, there are no standards for browser plugins(excluding HTML 5 as above with caveats). However, browser plugins are only part of the story. Merely extending the browser via plugins/DOM extensions is not enough. We need to address both i.e. browser plugins(DOM extensions) on one side and Native capabilities on the other side.

Consider a simple case like access to the address book from the browser. First, the browser must be capable of extensions i.e. DOM extensions. Secondly, the native capabilities i.e. the Address book API must be programmatically available. The second part(i.e. native access) involves security/privacy and other considerations. With Java ME, this takes the form of security domains and API protection groups.

As CEO explains, In the MIDP authorization model, a trusted application is one that is signed using X.509 PKI certificates and for which both its origin and integrity can be verified, and which is bound to one of the valid protection/security domains. These domains are Operator specific

Hence, any functionality that claims to access device functionality is hampered by an uneven security model depending on the Operator and permissions assigned to the application.

So far, the browser did not have this problem since there was no access to device APIs. Now that has changed – leading to potential problems and opportunities.

Some notes

a) Access to an application is different from access to data. Access to data is a more severe problem(for example actual entries in the address book).

b) An independent / user configurable policy may be needed else we will replicate the same problems from Java ME.

c) The gears security model addresses some issues with offline storage in the local cache. This is distinct from API access.

d) In general, access is a lot better with specific devices(like iPhone) but not mass market devices(yet)

e) A sandbox/privacy model may be needed for data

To conclude, Gears on mobile devices is a step in the right direction. It is no coincidence that it is deployed on Windows(and maybe iPhone). It still has a way to go to get to mass market. One advantage with Android/Google is access to a unified stack. This may work to create a mass market i.e. a Google certificate may span across different devices/operators.

Similarly, Nokia and the iPhone may lean towards a similar direction. My personal belief is: The Operator does not have a large enough user base(considering multiple devices/multiple operators within a country) to provide critical mass. It may be necessary for an umbrella body like GSMA/OMTP to take cross operator view to make this happen

thoughts?

Comments

  1. MChiu says:

    Ajit,
    I also found the announcement of Google Gears for windows mobile to be very interesting. However, it seems that iPhone 2.0 will be have native support for local persistence w/o Google Gears.

  2. Ajit Jaokar says:

    Thanks! yes you are correct Chiu. kind rgds Ajit