Hi, my name is Antony and I'm an engineer working on Google Chrome extensions.
I'm going to talk to you about a few topics related to the ids, packaging and distribution
of extensions in our system. If you choose to use the extensions gallery
to host and update your extensions, we take care of many of these details for you.
If you plan to do the hosting and updates yourself - or if you are just curious - it
can be helpful to learn more about these concepts. If you've tried making a test extension, you've
probably noticed that extensions have a strange looking id made up of 32 characters.
When we designed the system we wanted to have a single globally unique identifier for each
extension so that there are no conflicts with other extensions.
What we did NOT want was to require any central authority to assign these unique ids.
The mechanism we settled on uses one public/private key pair per extension, with the hash of the
public key determining the extension's id. Because of the way public keys are randomly
generated, the chance of a collision is extremely small.
If you host your extension on the gallery, we create and store the private keys for you
and when you want to release a new version of your extension all you need to do is log
in, upload the new source files, and hit the publish button.
Now I'll explore how the packaging and signature process works. Google Chrome extensions are
packaged into "crx" files. If you are using the gallery, we generate
the crx file for you when you hit the publish button.
If you want to host your extension on your own site, you'll create the crx file with
the "Pack Extension" button on the extensions management page in Google Chrome.
A crx file is really just a zip file of your extension directory plus 2 more things: the
public key, and a signature of the zip contents made using the private key.
When installing a crx, Google Chrome extracts the public key, signature and zipped content,
and makes sure the signature is valid using the public key.
What this means is that once users have installed a particular extension, they can get updates
to it and be sure that the new versions were signed by the same private key as the original
version. As with other types of software, developers
often want to update extensions to fix security problems, bugs, and make general improvements.
Google Chrome has a philosophy that client software should be a lot like web apps, where
you always use the latest version and don't have to do any work to get updates.
In the design of our extensions system we're following the same idea; so, we made auto-update
available to all extensions whether they are hosted in the gallery or not.
The way auto-update works is pretty simple - an extension specifies an autoupdate url
in its manifest, and the browser will check that url every few hours for an xml file which
lists the most recent version of the extension and where to download it.
The browser can fetch updated crx files over a plain, non-ssl connection because it will
check the signature inside the crx file before installing it.
If you're hosting your extension in our gallery, you don't need to worry about autoupdate,
we take care of it for you. If you're hosting your extensions yourself,
you just need to include an autoupdate url in your extension's manifest.json file.
I wanted to close this video by emphasizing a few important points for developers:
First, a crx file is really just a zip file with a little extra data tacked on.
Second, each extension has a public/private key pair, so if you develop 3 different extensions
you'll have 3 separate key pairs. And finally, protecting the private key is
very important if you are self hosting your extensions.
To learn more you can ask a question on our discussion group or check out our documentation
on the web at code.google.com/chrome/extensions.