W3C home > Mailing lists > Public > public-sysapps@w3.org > October 2013

Re: Privileged and certified-level app, was Re: Clarity over direction of work on runtime and security model?

From: Kostiainen, Anssi <anssi.kostiainen@intel.com>
Date: Fri, 4 Oct 2013 09:20:00 +0000
To: Marcos Caceres <w3c@marcosc.com>, Dave Raggett <dsr@w3.org>
CC: "public-sysapps@w3.org" <public-sysapps@w3.org>, Claes1 Nilsson <Claes1.Nilsson@sonymobile.com>, Kenneth Rohde Christiansen <kenneth.christiansen@gmail.com>, Anders Isberg <Anders.Isberg@sonymobile.com>
Message-ID: <2E9E690F-F0B7-4137-89AA-40741E74C4B7@intel.com>
On Oct 4, 2013, at 10:11 AM, Marcos Caceres <w3c@marcosc.com> wrote:

> On Wednesday, October 2, 2013 at 1:44 PM, Kostiainen, Anssi wrote:
> 
>> On Sep 25, 2013, at 1:48 PM, Marcos Caceres <w3c@marcosc.com (mailto:w3c@marcosc.com)> wrote:
>> 
>> [...]
>> 
>>> This means that, from the get-go, certified and privileged packaged apps cannot be shared across runtimes in an interoperable manner (without replacing the signature, which kinda defeats the purpose).
>>> 
>>> Question for the SysApps WG is: do we want to attempt to standardise a digital signature scheme for packaged apps?
>> 
>> A follow up question to the group, assuming digsig is scoped out:
>> 
>> What is the problem the group would like to solve by standardizing "unsigned" packaged apps that is not solved by "hosted apps" (for the sake of a better word) and ServiceWorkers (that will hopefully address the offline problem)?
> 
> There is probably not much.

I cannot come up with any compelling reasons either. Others?

> Packaged apps are  useful for products like PhoneGap and Blackberry WebWorks (that are then built/compiled to run on native platforms) - both PhoneGap and Blackberry already use W3C Widgets, so it would just be reinventing the wheel to re-standardize packaged apps. Guys from Adobe and Blackberry can correct me if I'm wrong, but it seems Widget's XML format is serving their platforms just fine. 

It sounds like the ship has already sailed what comes to spec'ing a new packaging format. W3C Widgets are used by some implementations while others may use something else. The industry has adapted by coming up with tools that make the packaging step rather transparent to developers. The return on investment may not be there for re-standardizing packaging.

I think we as a group should think about the following questions:

* Is this problem something that cannot be solved with existing technology?
* Are a significant number of implementers interested in supporting a yet another new format?

> Adding the ability to define an origin for an application ("e.g., <origin host='com.foo.bar'>") solves the only real outstanding issue for packaged apps: being able to work with CORS-enabled services. This then causes the Origin HTTP header to be: 
> 
> Origin: app://com.foo.bar 
> 
> (or whatever the developer wants). 

Are you interested in helping publish an update or an extension to Widgets to specify <origin>? This seems like a low hanging fruit to me. Would that be doable process-wise?

> Adding support for CSP tightening (and defining packaged apps in terms of CSP) is a nice to have - specially if developers can control this.

The same for CSP, perhaps less critical but would be good to get this in on the same pass.

> Personally I think we should kill the idea of a "hosted app" too. Segregating the Web into types of Web apps seems very unhelpful and risks creating badness: some apps may only work if installed, when they should work regardless in all browsers (including legacy ones).

Right. The web architecture is built around URLs for resource identification, HTTP for client-server interaction, and HTML for representation. HTML is increasingly a bootstrap to load scripts and other resources, but the big picture remains. HTML is the entry point.

I think we should keep these fundamentals in mind, and make sure what we do in this group fit into this picture. So personally I agree with you on that anything that deviates from the above fundamentals may be detrimental to the long-term health of the Web.

>> It seems the runtime-related bits on which to reach consensus on are:
>> 
>> * App Manifest
> Right - and this includes if we really need one. And if we do, what purpose it serves, what is/is-not covered by HTML, etc.

If there's a real problem this solves, whether this is defined as a bunch of <meta>s, for example, or a JSON document linked to the HTML with a <link>, does not matter, IMO. I think that's what you mean?

The above two questions apply to this as well.

>> * App Lifecycle and Events
>> 
> 
> This affects the Web at large so whatever we come up with, we need to make sure this is a browser solution (not a hosted apps, packaged apps thing).

Agreed.
  
> 
>> * ServiceWorkers
>> 
> 
> Nice to tie into the above. 

Indeed.

Dave - how close we are in getting this work into an appropriate W3C working group?

I'm wondering if rechartering the group would help align us around the revised goals, assuming we as a group land on a consensus we need to revise the goals and scope.

[On a related note, rechartering DAP helped the group make better progress with its deliverables.]

Thanks,

-Anssi
Received on Friday, 4 October 2013 09:20:44 UTC

This archive was generated by hypermail 2.3.1 : Friday, 4 October 2013 09:20:45 UTC