Extensions are written in JavaScript, HTML and stock web 2.0 tools like XMLHTTPRequest, CSS, and DOM. And then there are special extension APIs available through JavaScript. They don't effect significant changes in the Chrome UI; as Google developer leads put it on the Chrome extensions developer pages the point of extensions is to interact with content and the web, not with chrome (that's small c "chrome" in the sense of the menus, borders, icons and other non-content parts of the display.

There is one UI change an extension can make. Browser action extensions can create icons to the right of the address bar. These icons create a user interface for the extension and can display some simple text (called a "badge"). For instance, in the nearby image the red envelope icon is a GMail icon, and the "3" on it is the number of unread messages in my GMail inbox. If I click the icon, Chrome opens a tab with GMail in it. Browser action extensions can also draw a menu when the user clicks the icon. The menu is written in dynamic HTML.

Background pages are web pages that run in the extension process. They perform longer-term actions, such as managing state and interacting with the web. In the GMail extension example, the background page checks periodically with GMail to see if there is new mail available. If so, it tells the browser action page which describes the icon to update the badge. Content scripts use the HTML/CSS/DOM to make modifications to web pages. A content script could change color schemes for example.

Chrome extensions are generally simpler in scope than ActiveX controls or BHOs or Firefox add-ons which have full chrome access and can, for example, take complete control of the UI. But it's possible to write native code plug-ins for Chrome as well through the NPAPI (Netscape Plugin API). This is how, for example, Flash is implemented.

Extensions run in their own individual origin in the name-space (chrome-extensions://<extension-id>/element). Chrome runs them in their own processes, just like it runs web pages in their own processes. This should serve to protect Chrome and web pages from extensions and extensions from each other. In Windows, Chrome generally runs all these processes with DEP, ASLR and Low integrity, and they all run in the Chromium sandbox. (Note in the screen shot below that only the Flash plug-in runs at the normal Medium integrity.) Chrome is built with special libraries and a customized compiler that attempts to sandbox the native code on which Chrome and other in-process code runs. At this moment I'm running Chrome 6 tabs and several extensions and there appear to be 10 processes. Even if they're frugal, this can add up to a lot of overhead.

The security design of extensions just starts with process architecture. They are designed to observe principles of least privilege and privilege separation.

Least privilege in this context means that extensions can only access what they are designed to access. Every extension has a manifest file named manifest.json which specifies the files in the extension and the privileges it requires. These might include chrome namespaces it needs to access, such as the tabs, and it specifically includes any Internet domains with which the extension needs to communicate. So for example, the GMail checker extension only requests permission to access "http://*.google.com/" and "https://*.google.com/". It can't access any other domains, so even if there is a vulnerability in it, it can't be used, for example, to access my bank's web site.

(Incidentally, JSON, as in the .json extension for the manifest, stands for JavaScript Object Notation, a standard data description format, popular for applications such as these. It is also described in RFC 4627.)

Least privilege in the context of extensions does not prevent you from installing a malicious extension that asks for excessive permissions. Nothing in Chrome actually prevents that, but Google takes some other measures, as described below.

Privilege separation is expressed in the limits placed on different parts of extensions: for example, content pages can modify the HTML users see, but they have privileges to do little else. Background pages have much more substantial privileges, but they can't themselves directly access content.

Extensions are packaged in .CRX files. Like everything else these days, these are ZIP files; they contain the extension contents, a public key and a signature of the extension contents. Chrome uses the public key and signature from the CRX to make sure that the extension contents were signed by the private key associated with the public key. This also allows the client to confirm that any updates to the extension come from the same private key signer as the installed extension. The structure is very similar to a JAR file in Java.

This system is simple and elegant to a degree; the keys are not based on certificates from a verifying trusted authority, so you can't use them to identify the signer with any degree of certainty. This is consistent with Google's lax signature policies on Android (about which I'll be writing soon).

If you use the Chrome Extensions Gallery to distribute your extension, they will package up the CRX file for you. Google will examine your extension before making it public, but (unless you're doing something evil) it should go through rather quickly, with a few exceptions: For example, if you use the NPAPI, it will receive more detailed scrutiny. You can also self-host, in which case you have a little extra packaging work to do.

The Google scheme is a very large step up from security on Mozilla add-ons, which have no code signing at all. The only security for them is the SSL connection between clients and the Mozilla update server. Last year at BlackHat researcher Moxie Marlinspike demonstrated how such connections could be compromised and specifically laid out the procedures for creating a spoofed Firefox update server. Security in ActiveX controls for IE is both better and worse; controls may be signed, but they are pure native code that can do anything. So it's mostly worse. IE's BHOs, or Browser Helper Objects, have also turned into a security nightmare, and to the extent that I still run IE, I allow few, if any BHOs.

Updates are another big security advantage in Chrome. Each extension's manifest includes a URL that the browser uses to check for updates. The browser can then retrieve the updated CRX files, even over a plain http connection because the code signing allowed it to verify the signer.

I think of Chrome as another step in a broader movement away from native code and towards using normal web technologies to extend browsers. Microsoft is doing this on a small scale with accelerators in Internet Explorer 8; accelerators can do little, but what they do is hard to abuse. The code for them is XML that looks like an RPC definition, but which essentially describes an HTML form submission.

More substantially, Mozilla has a group working on an approach surprisingly similar to Chrome extensions which they call Jetpack. Jetpack is a new way to write Firefox browser extensions in HTML/CSS, and some APIs. The implementation details are different from Chrome, but the basic idea is the same. Perhaps the same process is in place at Mozilla, especially since at least some there feel that chrome support in the browser has been more trouble than it's worth.

The basic idea is a good one: extension code either needs to be trusted or managed and controlled, and I think we all know by now we can't trust it.

Google is clear that they're not done designing extensions, but I like what I see so far. Personally, I don't need a lot of fancy stuff, and what Chrome allows is fancy enough for me. As long as you don't use NPAPI code, the average Chrome extension should be a lot safer than the average extension to other browsers.