Permission Warnings

Contents

1. Examples of permission warnings
   1. h3Name
2. Warnings and their triggers
   1. h3Name
3. Permissions that don't cause warnings
   1. h3Name
4. Testing permission warnings
   1. h3Name
5. API reference
   1. Properties
      1. propertyName
   2. Methods
      1. methodName
   3. Events
      1. eventName
   4. Types
      1. id

To use most chrome.* APIs and extension capabilities, your extension must declare its intent in the manifest, often in the "permissions" field. Some of these declarations result in a warning when a user installs your extension.

When you autoupdate your extension, the user might see another warning if the extension requests new permissions. These new permissions might be new APIs that your extension uses, or they might be new websites that your extension needs access to.

Examples of permission warnings

Here's a typical dialog that a user might see when installing an extension:

The warning about access to data on api.flickr.com is caused by the following lines in the extension's manifest:

"permissions": [
  "http://api.flickr.com/"
],

Note: You don't see permission warnings when you load an unpacked extension. You get permission warnings only when you install an extension from a .crx file.

If you add a permission to the extension when you autoupdate it, the user might see a new permission warning. For example, assume you add a new site and the "tabs" permission to the previous example:

"permissions": [
  "http://api.flickr.com/",
  "http://*.flickr.com/",
  "tabs"
],

When the extension autoupdates, the increased permissions cause the extension to be disabled until the user re-enables it. Here's the warning the user sees:

Clicking the Re-enable button brings up the following warning:

Warnings and their triggers

It can be surprising when adding a permission such as "tabs" results in the seemingly unrelated warning that the extension can access your browsing history. The reason for the warning is that although the chrome.tabs API might be used only to open new tabs (chrome.tabs.create()), it can also be used to see the URL that's associated with every newly opened tab (using their Tab objects).

Note: As of Google Chrome 7, you no longer need to specify the "tabs" permission just to call chrome.tabs.create().

The following table lists the warning messages that users can see, along with the manifest entries that trigger them.

Permissions that don't cause warnings

The following permissions don't result in a warning:

• "chrome://favicon/"
• "contextMenus"
• "cookies"
• "experimental"
• "idle"
• "notifications"
• "unlimitedStorage"

Testing permission warnings

If you'd like to see exactly which warnings your users will get, package your extension into a .crx file, and install it.

To see the warnings users will get when your extension is autoupdated, you can go to a little more trouble and set up an autoupdate server. To do this, first create an update manifest and point to it from your extension, using the "update_url" key (see Autoupdating). Next, package the extension into a new .crx file, and install the app from this .crx file. Now, change the extension's manifest to contain the new permissions, and repackage the extension. Finally, update the extension (and all other extensions that have outstanding updates) by clicking the chrome://extensions page's Update extensions now button.