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.