Could Google Gears Make 'Cookies' Obsolete?

In what appears to be a serious and genuine attempt to take the lead in the growing Asynchronous JavaScript market - which was recently joined by Microsoft - Google may be trying to invent something that has already been invented before, perhaps several times: a way to implement a local data store for Web-based and remote applications run through the browser.

But what Google seeks to accomplish with its Gears toolset, released into beta this morning, may not be the invention itself but instead something all of its predecessors have failed to achieve: the establishment of an accepted standard.

Documents released by Google today show the company wants not only to develop a standard database mechanism for local clients using Web applications, but to encourage the rest of the industry to follow its methodology.

The key obstruction to the success of online, distributed applications over the last decade-and-a-half of the Web has been that there has been no single, accepted, reliable, and secure method for data to be maintained on behalf of local users, locally.

Users generally prefer for their personal data not to be stored on often unknown servers in frequently foreign countries. At the same time, they also prefer not to leave open any files to outside inspection, for fear (rightfully so) that the same mechanism that opens those files could open any others as well.

That said, Google Gears does not specify a new protocol, nor does it implement any security for transactions - for the latter, it relies upon session layer security, coupled with an adherence to the "same origin policy." Essentially, this means that no other identifiable resources are to be trusted for queries or requests other than the one which is running the local application to begin with - like a permanent blacklist.

Although this may seem contradictory to the whole notion of a distributed online application, realize that modular applications have varying scopes and contexts, and the functionality within which the Gears toolkit runs should be separated from the Web at large.

For example, Google's first application re-engineered for the Gears toolkit is its Google Reader application for maintaining simple RSS feed aggregation. You just can't store the user's repertoire of RSS feeds using cookies - the notorious small repositories for server-specific data on the client side - because cookies are typically pairs of data items (a name and its associated value) rather than lists of records.

It's tempting to create a text file on the client side which contains those records, but that would require access to the user's local file system - access which is typically blocked, with good reason.

Besides, for the running application to know for certain where a textual database file would be located, it might need to store that location in a centralized system file - for Windows, the System Registry. Giving any remote Web application even limited access to the System Registry is extremely dangerous.

So Google Gears' local store creates a data file that is accessible only from within the running Web application - only from the client side. Specifically, it can only respond to requests from the local application, placed using JavaScript Object Notation (JSON) - which is already well-utilized.

The Web doesn't access the local store; the Web application does. Therefore, there is no data interaction between a remote server and the local client's data store that isn't expressly specified by the JavaScript or AJAX application. A Web server may still request data from the local application, but it does not place the request to the local store directly - and the security of the entire architecture rests on this extra layer of abstraction.

Google's architectural model for Gears suggests that developers create an intermediate layer for handling data calls from a server, called a "Data Switch Layer." The poor naming of this concept alone is testament to the fact that all the other good names were taken, by concepts which have tried this before - most notably the data broker, which is a concept employed by both CORBA and Microsoft's Component Object Model.

In fact, besides its architecture and some more of its typically limited-vocabulary nomenclature, Google's principal contribution may not be technological at all, but rather a kind of unilateral movement to finally get browsers to implement a local data store in a rational way. And this time, because it's Google behind the movement, it could work.

A local data store would feasibly eliminate the need for cookies. Since cookies are very simplistic records, any type of server-side code could call upon them for purposes of tracking or recalling data about their user's behavior.

There's no way on the client side for software to ascertain whether a remote call to a cookie is being used for a purpose other than what the user might willfully permit, which is why anti-malware programs such as ZoneAlarm Pro and AdAware identify probable unwanted cookies by their origin rather than their presumed purpose.

If a Web site could instead place sophisticated database calls to a user's local store, conceivably, future client-side software could ascertain the nature of such calls, and perhaps permit or deny access according to policy-based rules set by the user.

So from a standpoint of security possibilities, the Google Gears scheme may become more preferable...assuming Web sites would be willing to open themselves up to being blocked on account of doubt on the part of their users. That's a big assumption, which may be why services that perform user browsing habits analysis using cookies, for instance, may stick to doing so.

Of course, if the Gears methodology catches on, users may become more inclined to block all cookies from sites that aren't willing to evolve. In such an event, Google Gears may end up contributing to the evolution of Web applications one way or the other: by evangelizing the open source development community, or by setting up the existing order of the Web for a long overdue round of obsolescence.