the Chromium logo

The Chromium Projects

Extensions Manifesto

Problem statement

Chromium can't be everything to all people. People use web browsers in a variety of environments and for a wide variety of jobs. Personal tastes and needs vary widely from one user to the next. The feature needs of one person often conflict directly with those of another. Further, one of the design goals of Chromium is to have a minimal light-weight user interface, which itself conflicts with adding lots of features.

User-created extensions have been proposed to solve these problems:

Goals

An extension system for Chromium should be:

Use Cases

The following lists some types of extensions that we'd like to eventually support:

This list is non-exhaustive, and we expect it to grow as the community expresses interest in further extension types.

Proposal

We should start by building the infrastructure for an extension system that can support different types of extensibility. The system should be able to support an open-ended list of APIs over time, such as toolbars, sidebars, content scripts (for Greasemonkey-like functionality), and content filtering (for parental filters, malware filters, or adblock-like functionality). Some APIs will require privileges that must be granted, such as "access to the history database" or "access to mail.google.com".

Extension components will typically be implemented using web technologies like HTML, JavaScript and CSS with a few extra extension APIs that we design. Extensions will run in their own origin, separate from any web content, and will run in their own process (with the exception of content scripts, which must run in the same process as the web page they are modifying). Some form of native code components may also be supported, but the goal is to minimize the need for this in extensions.

Packaging and Distribution

For performance reasons, extensions will need to be loaded out of a local cache. Extensions need to be loaded immediately at startup, ideally before pages are loaded, yet shouldn't affect startup time. Out of date versions are still served from the cache until a new version has been completely downloaded and validated. All extensions will have a manifest that includes information such as: the name and description of the extension, the URLs to the various toolbars, workers, and content scripts that compose the extension; and an autoupdate URL and public key for validating extension updates. There will eventually be three mechanisms for packaging and distributing extensions:

  1. A signed package of resources in a single file, served out of a local cache
  2. A collection of "live" resource URLs served over SSL
  3. A collection of files served off of a local filesystem out of a well-known directory. This is primarily for development purposes, but can also be used for pre-bundled extensions.

Initially, we'll implement only 1 and 3. To implement 2, we'll need an implementation of the HTML5 app cache. This is because typical cache behavior such as eviction is not acceptable for extensions. Even when the app cache exists, the resources will still need to be served over SSL to prevent man-in-the-middle tampering.

The signed package mechanism will be a zip file with the manifest in a specific name/location. These files would be created with a custom tool that we provide that handles validation, manifest creation and signing. This tool could be part of an online hosting / authoring service for extensions (see below).

Installation

Installation of extensions should be a simple and minimal interface, ideally consisting of only two clicks. A link to an extension is embedded on a web page and a user clicks on it. A confirmation dialog is presented that lists the permissions that the extension requires. This is an all or nothing proposition - if the user doesn't want to give a particular privilege, they can't selectively disable one. If they decline, the extension will fail to be installed. An extension can't request "optional" privileges.

Most extensions should be able to load in place without forcing a browser restart or even a page reload when they are installed.

An interface will be available which allows users to review the extensions that they have installed and what privileges these extensions have. From this interface it will be a simple operation to temporarily disable extensions or permanently uninstall them.

Automatic Updates

Similar to Google Chrome, it is important for security that extensions be able to silently update. This should be a capability that is present for all extensions by default, not something the author has to plan for.

In the case where an updated extension needs new privileges, we will prompt the user that the extension needs "to be updated", which will essentially start the installation phase again, prompting the user for the extra privileges. Ideally this UI should work in a non-modal, minimally-intrusive way. We need to decide what happens when the user says no to these new privileges (upgrade simply fails, or extension is disabled).

Extension updates will be performed over HTTP while Chromium is running. The downloaded package will be digitally signed to prevent MITM attacks. The initial signature will be implicitly trusted. Updates will only be applied if the version number is greater than the installed version number.

We will provide a service designed to reduce burden to developers by reducing traffic costs and providing a robust, secure mechanism for autoupdates that they can easily leverage rather than having to handle the logistics on their own site. It would also provide authors with a way to easily create and verify their extension packages and manifests. However, developers will always have the option to package, sign, and host extensions on their own site.

The central service will maintain a blocklist of known malicious or harmful extensions. This blocklist will be used by the browser to disable these extensions.

It's likely in the future we may want to provide a consumer front-end which would allow users to more easily find the most popular, highest quality and trustworthy extensions.

API details

We've published a list of potential APIs. Details are published in the Browser APIs document as they are designed.

Next Steps

Our first milestone will be to implement a functioning extension system that can support content scripts. The majority of the work will be the infrastructure, including:

Once we have content scripts working, we can move on to additional types of extensibility like toolbars, sidebars, etc.