Google Chrome to Get Extensions Framework

The very fact that Google put Aaron Boodman on the Chromium project should have told us something.  Aaron invented the popular GreaseMonkey add-on for Firefox, and on Saturday he announced the publication of a design document for adding extensions to Google Chrome.

The lack of extensions for Chrome has been a major barrier to adoption of the new browser.  I’ve been using Chrome as my default browser since I reviewed it back in September, and add-ons are perhaps my most missed Firefox feature — with the possible exception of RSS autodiscovery and customizable subscription.

Many Firefox users identify a single extension as the main reason they haven’t moved to Chrome: AdBlock.  For Google to allow an extension in its browser that would block its own ads might seem like cutting off your nose to spite your face, but it appears that these users may get their wish.  AdBlock is specifically mentioned as a use case in the design document for the new feature.

Many of the design goals seem specifically designed to overcome the frailties of Firefox add-ons.  Here are a few that scream out, “I’m looking at you, Firefox!”:

• We should not need to disable deployed extensions when we release new versions of Chromium.
• Extensions should not be able to crash or hang the browser process.
• Chromium should assign blame to extensions that are overusing resources via tools like the task manager and web inspector.
• Poorly behaving extensions should be easy to disable.
• Extensions need to be loaded immediately at startup, ideally before pages are loaded, yet shouldn’t affect startup time.
• Most extensions should be able to load in place without forcing a browser restart or even a page reload when they are installed.
• Similar to Google Chrome, it is important for security that extensions be able to silently update.

The authors mention that each extension should run in its own process, just as Chrome handles separate web pages — and that these processes should be “sandboxed” to prevent access to the local machine.  The one exception would be content scripts (like GreaseMonkey) that would have to run in the same process as the content they’re modifying (really?  you couldn’t pipe it through?).

The “silent update” facility will be driven by a central repository of extension updates.  A central service will also keep track of known harmful extensions.  The browser can check this service to disable those extensions.

The APIs have not yet been specified at all, other than to mention some hopeful categories: “toolbars, sidebars, content scripts (for GreaseMonkey-like functionality), and content filtering (for parental filters, malware filters, or adblock-like functionality.”

Each extension will be accompanied by a manifest, written in JSON, which seems to be the most detailed part of the proposal so far.  No word yet on when we can expect more.  Personally, I can’t wait.