W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

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

From: Aaron Boodman <aa@google.com>
Date: Tue, 16 Jun 2009 10:24:14 -0700
Message-ID: <278fd46c0906161024h4cdfd340j5f09377b3b507ceb@mail.gmail.com>
To: Robin Berjon <robin@berjon.com>
Cc: Adam Barth <w3c@adambarth.com>, public-webapps <public-webapps@w3.org>
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.

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.

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.

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

- a
Received on Tuesday, 16 June 2009 17:24:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:54 UTC