W3C home > Mailing lists > Public > public-sysapps@w3.org > April 2014

RE: Discussing security model of sysapps

From: POTONNIEE Olivier <Olivier.POTONNIEE@gemalto.com>
Date: Tue, 1 Apr 2014 17:38:10 +0200
To: Dave Raggett <dsr@w3.org>, GALINDO Virginie <Virginie.GALINDO@gemalto.com>
CC: Wonsuk Lee <wonsuk11.lee@samsung.com>, Mounir Lamouri <mounir@lamouri.fr>, "public-sysapps@w3.org" <public-sysapps@w3.org>
Message-ID: <267D4E63A0D73044BFBB4199DA94D80504199075689B@CROEXCFWP04.gemalto.com>
Thanks Dave for this good status overview. I would however like to comment on 2 points:

You say:
> ... 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.

There is not interoperable way to do this. The manifest is not sufficient, unless we add additional data in it, to download the full set of application's resources. What is a "packaged" app and how to download it is not specified.

You say:
> Apps may be divided up according to whether they have a digital
> certificate from a trusted third party.

The is no specification defining how to attach a signature to a SysApp (there was widget signatures though, but this is not applicable to Sys Apps as is). This is probably something we have to address.

Thanks
--
Olivier

> -----Original Message-----
> From: Dave Raggett [mailto:dsr@w3.org]
> Sent: Tuesday, April 01, 2014 10:01 AM
> To: GALINDO Virginie
> Cc: Wonsuk Lee; Mounir Lamouri; public-sysapps@w3.org
> Subject: 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
>


This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus
Received on Tuesday, 1 April 2014 15:38:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:36:20 UTC