Re: Widgets 1.0: Packaging and Configuration feedback

Hi Michael,

>  >  I would like to see your list of proposed capabilities as it might be helpful.
>  Okay.  It is being reviewed internally at the moment so I'll hopefully
>  be able to send it out early next week.

Great to hear it! looking forward to it.

>  >  There is currently no
>  >  relationship between a digsig and capabilites afforded to the widget
>  >  by the widget user agent.  This may change in the future (but would be
>  >  unfair to developers who can't afford to buy a code signing
>  >  certificate).
>  I don't see how this is different to Java or any other privileged web
>  application.  Without a digital signature the widget runs in a sandbox
>  environment.  With a digital signature, subject to the UA's security
>  policy, the widget may be allowed to perform privileged operations.

This Java-like-model would favor well-off developers over independent
developers as it would mean that people would have to buy expensive
code signing certificates (eg. a  standard verisign code cert is
US$499/year!) and possibly send it to a company for verification.
That's unfair and hardly open. I would personally be against such a
security policy.  If a vendor wants to do that in their
implementation, then OK - that's their business (For example, Company
X may choose to only run widgets that have been QA tested in their

Personally, I will object to this model being in the spec in favor of
a more open model.

>  Regarding the cost of code signing certificates that is something of a
>  religious debate and not something I want to get into, surfice to say
>  that such certificates do not need to be expensive and the w3 are in a
>  good position to work with browser vendors to ensure a good selection
>  of root certificates are included with browser distributions.

I hardly think that is something of a religious debate, and I strongly
believe it is a debate that we need to have because it is fundamental
to the security model we are trying to define. It is evidently costly
to both signers and developers to enter into the security model you
are describing. That is, one that would require the signer to verify
that the developer has not put any malicious code into the widget and
thus grants permissions based on a signature (this requires some
serious QA processes).

You are also partly suggesting that we standardize the Root certs that
ship with widget engines. I'm not sure we can do that. We have a
requirement that mandates that widget user agents allow users to add
their own certificates (so then companies and individuals can
self-sign their widgets, etc). However, making a security policy based
on certs seems dangerous because if a user installs a nasty
certificate, then nasty widgets can end up with elevated privileges.
I'm not sure how we solve this problem yet, and would like to work
openly to solving it.

At this point, the sole purpose of the digital cert is to provide
authenticity, data integrity, and non-repudiation.

>  >  >  4.2.  Mandate that config.xml will always be the first entry in a
>  >  >  widget archive
>  >
> > That would be difficult for authors because they would require a
>  >  special tool (As an author, I should just be able to select the files
>  >  that make up the widget and make a zip file; an author does not care,
>  >  nor should they care, what order the files are in). Also, your
>  >  proposal goes against our KISS design goal (see requirements document,
>  >  linked from the design goals section of the spec).
>  >  ...the efficiency gains are tiny.
>  I'm not sure I agree with that.  No special tool would be required -
>  just to put the config.xml as the first argument.  But wouldn't you
>  have special tools to validate the config file and sign the archive
>  anyway?

As Bjoern said, you are assuming some kind of special (command line?) tool.

It is a requirement that packaging tools be readily available as part
of every OS (ie. out of the box) without needing the author to acquire
any special tools or, if can be avoided, having to drop into a command

>  The efficiency gains are significant enough on embedded platforms.

I understand and if you have some evidence of that, I would like to
see it. However, putting the config file first would not help when a
widget is localized (as the widget user agent needs to search for the
localized config.xml file anyway, and that could be anywhere off the
root folder (eg. en-us/config.xml)).

>  One can parse the file once as it comes over the wire and use a small
>  memory buffer, writing the decompressed files out to persistent
>  storage or directly into the browsers' cache one by one.  One of those
>  three benefits has to go as soon as one cannot rely on the manifest &
>  checksums being the first file in the archive.

Like I said previously, adding support of this feature comes at the
cost of requiring a special tool to create the package. If a vendor's
implementation will work faster if the config file is the first file,
then they are free to develop a special tool to appropriately place
the config file wherever it is most convenient  (ie. we should leave
this as a point on which user agents can compete). Vendors may also
provide development guides or tutorials that instruct authors how best
to package their widgets to get maximum efficiency out of their

Kind regards,
Marcos Caceres

Received on Tuesday, 13 May 2008 02:23:26 UTC