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

Hi Aaron,
Thanks for this info! really interesting... just a few questions below...

On Tue, Jun 16, 2009 at 7:24 PM, Aaron Boodman<aa@google.com> wrote:
> On Tue, Jun 16, 2009 at 4:11 AM, Robin Berjon<robin@berjon.com> wrote:
>> Just out of curiosity, would you mind expanding on the "design ideas" that
>> you share with widgets that make you so happy? We're interested in happiness
>> :) Also, do you think that beyond design ideas you could at some point reuse
>> the concrete specifications that we've developed, and if not why, what's
>> missing, etc.? Thanks!
>
> The intent of the Chrome extensions system is to reuse as much of the
> web platform as possible, just like with Widgets. In actual
> implementation, they are zipped packages of HTML, CSS, and JavaScript,
> which is similar to your design.

Nice.

> 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?

> 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.

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

> So there are multiple surfaces
> where you can run HTML pages that are tightly coupled to the visual
> design of a browser (toolbars, sidebars, urlbar, etc). Similarly the
> APIs you have access to as a developer are frequently browser-related:
> bookmarks, history, etc.
>
> But the good thing is that as everyone seems to converge on HTML as
> the core of their systems, reuse gets easier and easier. If somebody
> did want to repackage an extension as a widget, it should be possible
> to reuse a lot of the code directly.

Yes, I can certainly see that on the code path there would not be much
problem (aside from the proprietary bookmarks, history,  etc. APIs).

Kind regards,
Marcos
-- 
Marcos Caceres
http://datadriven.com.au

Received on Wednesday, 17 June 2009 13:19:31 UTC