RE: Widgets - WARP, Widgets Updates and Digital Signatures

Hi Nathan,

Thanks for clarifying your proposal.

I interpret you so that you are proposing standardization of a general concept of "packaged and installed web applications". Something like http://code.google.com/chrome/apps/docs/index.html plus additional features from widgets specifications.

This is something that can have a value by several reasons, for example: 

* Whole application package or only manifest/configuration file could be digitally signed.
* Permission to use APIs could be given at installation time.
* Manifest/configuration file could define network access limitations.
* Web application marketing/deployment/charging advantages.  

I agree that the specifications you mention are applicable for a general concept of "packaged and installed web applications" but I believe that currently most people have the view that "widgets" are "packaged and installed web applications" that run small "live" applications on the home screen. However, what does the widgets specifications actually say? I haven't digged into the documents in detail but are they not already enabling a general concept of "packaged and installed web applications"? 

So far there has been a distinction between "browser", running dynamic content on web sites and "widget user agent", running installed web widgets. Reading you original mail in this thread you say:
" Simply wondering why WARP, Widgets Updates and Digital Signatures aren't used to deploy js applications which run in the main browser context?".

So, what are you actually proposing?

* Update to HTML5 to support "packaged and installed web applications" in the "main browser context"?
Plus
* Updates to the Widgets specifications to enable the more general concept of "packaged and installed web applications"?

Furthermore, do we really want "packaged and installed web applications" to run by the same user agent, i.e. the normal browser as normal website based web applications? We may want to have different "user agent chromes" depending on type of web application.   

Best regards
  Claes

> -----Original Message-----
> From: Nathan [mailto:nathan@webr3.org]
> Sent: den 8 september 2010 18:27
> To: Nilsson, Claes1
> Cc: Frederick.Hirsch@nokia.com; public-device-apis@w3.org
> Subject: Re: Widgets - WARP, Widgets Updates and Digital Signatures
> 
> Hi Claes,
> 
> I think the main thing that's missing from the proposal is context :)
> 
> With the advent of client side persistence solutions and ever
> increasing
> device/browser capabilities, it's now possible to make 100% client side
> js applications which run in the browser, everything from small games
> and micro-blog clients right up to full document/image editors. There
> is
> a strong shift in this direction from many corners of the web.
> 
> Currently application developers can choose between:
>   (1) hosting the client side application on a 'website'.
>   (2) creating a vendor specific 'extension'.
> 
> When really, what we all want/need is to be able to 'install' an
> application which runs in the main browser context (i.e. can be used
> off
> line, can be packaged as an application, can be signed, can contain an
> access request policy).
> 
> You might think of this as cross between a Mozilla Prism, browser
> extensions, widgets and traditional web applications. Universal web
> applications that can run on any device.
> 
> To my untrained eye, it appears that virtually everything needed to
> take
> a series of scripts & resources and wrap them up in a manner similar to
> extensions is already spec'd out in the various widget specifications.
> Everything needed to run the applications universally is already
> provided by any user agent on any device that implements
> js/html/web-apps/device apis.
> 
> Thus, the suggestion to scope using the widgets specifications as a way
> to package all this up and give the world universal web applications
> which run on any device and provided the needed
> packaging/signing/access-request/update side of things.
> 
> Best,
> 
> Nathan
> 
> Nilsson, Claes1 wrote:
> > Hi,
> >
> > Assuming I don't misunderstand the proposal/questions I would say:
> >
> > * WARP: Might work for main browser context?
> >
> > * Digital Signatures for Widgets: I guess that using "Digital
> Signatures for Widgets" for normal web application running in the
> browser wouldn't work as this specification assumes signing of an
> installed package. For web applications running in main browser context
> the corresponding specification is xmldsig
> (http://www.w3.org/TR/xmldsig-core/), that makes it possible to sign
> defined parts of web content. However, as far as I know this
> specification has not been much implemented as it is considered
> complicated. Don't know any details.
> >
> > * Widgets Update: Don't see the meaning of this for browser context
> as this specification assumes an installed package.
> >
> > Regards
> >   Claes
> >
> >> -----Original Message-----
> >> From: public-device-apis-request@w3.org [mailto:public-device-apis-
> >> request@w3.org] On Behalf Of Frederick.Hirsch@nokia.com
> >> Sent: den 7 september 2010 20:24
> >> To: public-device-apis@w3.org
> >> Cc: Frederick.Hirsch@nokia.com; nathan@webr3.org
> >> Subject: Fwd: Widgets - WARP, Widgets Updates and Digital Signatures
> >>
> >> Forwarding with permission .
> >>
> >> What do you think of this approach?
> >>
> >> regards, Frederick
> >>
> >> Frederick Hirsch
> >> Nokia
> >>
> >>
> >>
> >> Begin forwarded message:
> >>
> >>> From: ext Nathan <nathan@webr3.org>
> >>> Date: September 3, 2010 1:52:26 PM EDT
> >>> To: public-webapps <public-webapps@w3.org>
> >>> Subject: Widgets - WARP, Widgets Updates and Digital Signatures
> >>> Reply-To: "nathan@webr3.org" <nathan@webr3.org>
> >>>
> >>> Hi All,
> >>>
> >>> Simply wondering why WARP, Widgets Updates and Digital Signatures
> >> aren't
> >>> used to deploy js applications which run in the main browser
> context?
> >>> seems like a nice solution that would work webscale, and which
> would
> >>> provide further user security, identification of trusted apps and
> >> cover
> >>> the other half of CORS which is informing and protecting the user.
> >>>
> >>> Perhaps one of the vendors has already implemented in the main
> >> context?
> >>> Best,
> >>>
> >>> Nathan
> >>>
> >
> >
> >

Received on Friday, 10 September 2010 12:33:22 UTC