Gears and Security

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

Contents

  1. Basic Security Model
  2. Permissions Dialog
  3. Security of End-User Data
  4. Best Practices

Basic Security Model

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 Gears:

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, Gears shows a warning dialog when a site first attempts to use the Gears API. User opt-in is important because 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 is only until the page is reloaded, though users can also choose to never allow a particular site to access Gears. Remembered decisions can later be changed using the Gears Settings dialog, located in the browser's Tools menu.

Security of End-User Data

Gears data files are protected with the user's operating system login credentials. Users with separate login names cannot access each other's 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.