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:
An extension system for Chromium should be:
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.
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".
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:
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 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.
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 blacklist of known malicious or harmful extensions. This blacklist 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.
We've published a list of potential APIs. Details are published in the Browser APIs document as they are designed.