Google Gears and Security

This page describes the security model used in Google Gears, and discusses what developers can do to build secure applications.

Contents

Basic Security Model

Google Gears uses the same origin policy as its underlying security model. A web page with a particular scheme, host, and port can only access resources with the same scheme, host, and port.

This means a site using Google Gears:

• Database: Can only open databases created for that site's origin.
• LocalServer: Can only capture URLs and use manifests from the site's origin.

Sometimes web applications on different origins may want to share resources. We are investigating ideas for granting permissions across origins.

Permissions Dialog

To protect users, Google Gears shows a warning dialog when a site first attempts to use the Google Gears API. User opt-in is important because Google Gears allows applications to store data on the user's hard disk.

Users can grant or deny access for each security origin. When a user grants access to Gears for a particular origin, Gears remembers this decision for future visits. Denying access to Gears is only remembered until the page is reloaded. Users can also choose to never allow a particular site to access Gears. Remembered decisions can later be changed using the Google Gears Settings dialog, located in the browser's Tools menu.

Security of End-User Data

Google Gears data files are protected with the user's operating system login credentials. Users with separate login names cannot access each other's Google Gears data files, as enforced by the operating system.

On the other hand, two people using the same OS login could theoretically access each other's Gears data files, just as they could access any other file on the machine.

Best Practices

Database Security

Best Practice:: Avoid SQL injection attacks. Never insert user input directly into a SQL statement. Instead, use substitution parameters in Database.execute().

An attacker may run unintended SQL commands using a technique called SQL injection.

To avoid this, developers should pass user input to SQL statements only through the question mark (?) substitution parameter. This way, the input will get correctly escaped before being executed.

For example, write this:
    db.execute('insert into MyTable values (?)', data);
instead of this:
    db.execute('insert into MyTable values (' + data + ')');

User Opt-In

Best Practice: Store offline preferences locally. Applications should treat a user's "enable offline features" choice as a per-machine setting.

Users may run your application from multiple machines, and they may not want their data stored locally on every machine. For this reason, store the choice in a local database.