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

Hi,

See my comment below on hosted apps.

BR
 Claes

________________________________________
From: Kostiainen, Anssi [anssi.kostiainen@intel.com]
Sent: Friday, October 04, 2013 11:20 AM
To: Marcos Caceres; Dave Raggett
Cc: public-sysapps@w3.org; Nilsson, Claes1; Kenneth Rohde Christiansen; Isberg, Anders
Subject: Re: Privileged and certified-level app, was Re: Clarity over direction of work on runtime and security model?

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.

[Claes]: I am not sure that I interpret Marcos correctly, but it seems as you argue that "hosted web sysapps" and webpages running in the normal browser context are the same. However, I think that what Ansi says is an argument for "hosted web sysapps". So installing a manifest on the device and having the web application content on servers instead of on the device in an installed package has several advantages. For example, users will always get the latest version of an application without having to be bothered with application updates, Furthermore, Dave just referred to the SysApps charter in another mail and stated,  "SysApps is responsible for aspects specific to the needs for system applications, i.e. security contexts other than the regular browser context". So SysApps should define standards, in addition to what we already have, that make it possible to provide more sensitive APIs to system web applications than is possible in a browser context. Our view is that this also includes web system applications for which the content resides on web servers.

I don't want to go into details of solutions for these use cases but I imagine some model like:

* The manifest is signed by a trusted appstore and installed into the device.
* The manifest points to app content on a trusted server (for example according to a proposed manifest "origin" attribute).
* Content Security Policy is set to: script-src 'self', which means that scripts must come from the same trusted site.
* App content is dowloaded through secure TLS transport.
* If needed the app store can revoke the manifest and by that revokate the whole app

However, exactly what we, in the SysApps WG, needs to standardize to achieve this and what can be device vendor, app deployer, etc, specific, is a subject for further discussion.

>> 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 11:20:25 UTC