Re: [widgets] Public keys in widgets URI scheme?

On Wed, Jun 17, 2009 at 6:18 AM, Marcos Caceres<marcosc@opera.com> wrote:
> On Tue, Jun 16, 2009 at 7:24 PM, Aaron Boodman<aa@google.com> wrote:
>> But the thing I was talking about that we have been very happy with
>> was the idea of using a public key as the unique identifier for an
>> extension. This has worked very well for us. Every extension has an
>> RSA key pair and the public key is the extension's one true unique ID
>> (but for convenience, we also use a hash of the public key as an ID in
>> some places). Every deployed instance of the extension is signed with
>> this key pair.
>
> Does that mean that Google must sign every package? Can unsigned
> package be deployed?
>
>> One interesting outcome of this is that it is impossible to have ID
>> collisions. In systems where a GUID must be chosen by a developer,
>> developers sometimes accidentally or maliciously copy the ID of
>> another extension. This is not possible if the unique ID is the public
>> key because the developer would have to know the private key, too,
>> since every extension must be signed by the private key.
>
> Is that the developer's private key, or the vendor's (Google's) key?

Neither. Each extension has its own distinct key pair which stay
constant across versions. That is to say, extension are self-signed.
The key pair can be generated using standard tools (the openssl
command line tool), or the Chromium/Google Chrome binary.

This scheme allows us to autoupdate extensions over normal HTTP
without SSL because the signature proves that whoever created the
first version of an extension created all subsequent versions.

>> As for reusing the actual widgets spec, I think that there are some
>> important differences. Chrome extensions are intended to extend the
>> actual Chrome UI, not stand alone.
>
> I see, but you conceptually package things in the same way as widgets.
> I'm interested to see that you guys opted to put the signature and the
> "manifest" as the first bits of data of a package. Does that mean that
> chrome extensions cannot be read/opened by standard zip tools (I just
> tried this on my Mac, and seems to be the case)? If so, I guess that
> also means special/proprietary tools are needed to create chrome
> conforming packages for distribution.

The zip format actually allows arbitrary data at the beginning of the
package, but many tools (importantly the built-in ones in Windows and
OS X) appear to not support this.

This seemed like an OK trade-off to us. As a last resort, the
Chromium/Google Chrome binary itself can be used to unpack the files
(by registering itself with the OS for the .crx extension).

> Aside from optimization reasons, was there any other reason why Chrome
> went down this route?

We want to be able to do content-sniffing to determine if a package is
an extension, and not rely on a content-type alone (it is difficult
for many developers to set content types on their servers). This
implies that extensions have a known header that can be scanned for.

- a

Received on Wednesday, 17 June 2009 18:31:01 UTC