Re: Widgets 1.0: Packaging and Configuration feedback

Hello Marcos,

Thanks for your prompt reply.


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

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

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.

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

The efficiency gains are significant enough on embedded platforms.
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.

-- 
Michael

Received on Monday, 12 May 2008 13:38:04 UTC