Re: Discussing security model of sysapps

On 01/04/14 15:14, GALINDO Virginie wrote:
> Hi Dave,
>
> I think that the WG should make decision on the questions I raised, and *after* you will be able to write a white paper. Or you will write your view and it will be challenged by the WG, and you will waste your time. That WG discussion would be about one hour. To make sure we get some consensus there. Specially the question whether we should forget the idea of trusted application via a signature, to endorse a trusted application via a user permission system is to be debated. If the last one decision was take, I would highly recommend the WG to start thinking seriously about permissions, now.
>
> I can definitely help you reviewing your white paper, as I proposed in previous F2F meeting to have such a paper explaining the security and execution model.

Okay, let's ask if Wonsuk and Mounir can allocate 1 hour to the 
discussion. I was planning on writing the white paper after the meeting, 
when as you suggest we should have clarified where we have consensus and 
where we do not.

Based on what I have heard so far, trust seems to be based on a 
combination of whether the app is pre-installed, has a digital 
certificate from a trusted party, or has been approved by the end user, 
either at install time, first run, or when the app first tries to access 
a given capability.

Here is something to seed discussion and to hopefully expose any 
misunderstandings I may currently have:

By default, web browsers take a very cautious approach to security, as 
users may load web applications from unknown and untrusted sites. The 
APIs provided in the regular browser security context tend to be 
restricted and to require user confirmation where this would impact the 
user's privacy. An example is where an application would like to access 
the device's microphone or camera. The browser asks the user to confirm 
or deny access for this on the basis of the web application's URI (as 
shown in the location field in the browser UI).

Native applications, e.g. for Android, have access to a much richer 
range of APIs, for example, free access to the device's storage, and to 
raw IP sockets. The user is presented with a long list of required 
capabilities at the time the application is installed. There is little 
explanation of how the application will use the requested capabilities, 
and users are required to say yes if they want to try out the 
application. When the application first runs, users will in many cases 
be asked to agree to legal terms and conditions. This is again something 
where users are conditioned to say yes. In essence, users rely on the 
brand of the app as a basis for its trustworthiness. Anti-malware apps 
such as Lookout and AVG provide a backstop, but do little to protect 
users' privacy.

There is growing interest in being able to use the open web platform as 
a cross platform alternative to native apps. This led to the launch of 
the W3C System Applications working group. This group includes people 
from a number of different projects, e.g. FirefoxOS, Tizen, ChromeOS, 
and Apache Cordova (PhoneGap) as well as others with a general interest 
in enabling system level APIs for trusted web applications.

Web applications consist of a set of component resources, e.g. HTML, 
JavaScript, style sheets, images and so forth. These can be packaged 
into a single file, but there is a lack of agreement on the details of 
how that is done. Instead, there is a general consensus on using a 
manifest for the web app's metadata. Browsers can download this along 
with the rest of the app's components, avoiding the need for packaging.

The W3C WebApps working group is standardizing a JSON based manifest 
format. The editor's draft for this can be found at:

     http://w3c.github.io/manifest/

This is based on the requirements for installable web apps as described at:

     http://w3c-webmob.github.io/installable-webapps/

The manifest includes the application name, links to icons, the default 
orientiation, and whether to open the app full screen, etc. The SysApps 
WG expects to standardize the manifest names for capabilities associated 
with the SysApps APIs. These can be used by the browser to ask the user 
for confirmation when the application is first run.

In principle, capabilities can be left out of the manifest, resulting in 
the user being asked for permission when an API is invoked by the 
application. This may be easier for the user to understand, due to the 
context in which the capability is needed. In some cases, the user's 
action can itself be taken as implicitly granting permission for a given 
capability.

Apps may be divided up according to whether they have a digital 
certificate from a trusted third party. Some capabilities may be 
excluded without such a certificate. If an app without a recognized 
certificate tries to access such capabilities, the browser would block 
access without asking the user. Some APIs may only be accessible to 
pre-installed apps. For automotive, this could pertain to internal 
vehicle APIs.

SysApps is standardizing the application lifecycle and events, see:

http://www.w3.org/2012/sysapps/app-lifecycle/

This enables apps to provide a script that runs in the background and 
responds to app life cycle events such as launch and terminate, system 
events, e.g. associated with push notifications, and scheduled wake up 
calls. This builds upon the service worker specification being developed 
by the WebApps working group. It essentially allows system events to 
launch web applications when needed, and to do so without draining the 
battery in the interim.

My understanding is that the security model is the same for packaged and 
non packaged apps. Where the highest level of trust is required, APIs 
may only be accessible to pre-installed apps. Such APIs may only work 
with a single such app.  Apps installed from an app store or website, 
would be digitally signed, enabling checks on the integrity of the app's 
components.

Best regards,

-- 
Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett

Received on Tuesday, 1 April 2014 15:01:22 UTC