Application Security Controls


This area defines in detail how applications are authenticated, signed and certified. It also defines how the runtime constraints placed on applications and how they communicate securely with the PZP and external services.

1 Types of application

Because webinos allows for applications running within different renderers and with different levels of certification, we define the following types of application.

Type   Runs in   Local / hosted   Widget Manifest?   Delivered over   Installed?   Authentication  
B-A Browser Hosted (+ app cache) Yes HTTPS Yes TLS certificate, root trusted by browser
W-R Widget renderer Combination Yes File + HTTPS Yes Signed widget authenticated by widget processor. 'Recognised' as per (WAC). HTTPS traffic only from recognised origin.
W-U Widget renderer Combination Yes File + HTTPS Yes Signed widget, but unrecognised identity (WAC). HTTPS traffic only from recognised origin. HTTPS traffic authenticated by widget runtime OR connected to same entity as the widget signature.

There is no distinction between hosted applications and local applications. This is because webinos supports widgets that are mixture of both.

All applications must have a configuration file corresponding to the webinos specifications, even hosted applications viewed in a web browser.

2 Application (widget and browser) installation

Applications may be installed by users, by device manufacturers shipping webinos, or as part of the webinos installation as bundled by webinos developers. "Installation" refers to the registration of a web application with the client-side webinos framework. In this section we describe only installation by users after the platform has been installed. This specification does not describe where applications may come from.

The installation of an application is the time when a trust decision must be made. If the application is not trusted at all, it should not be installed. If there is doubt about the provenance of the application - whether it is from the right source and has the right name - it should also not be installed. The following steps are taken from WAC (WAC) and modified for the webinos install process:

2.1 Widgets will be "installed" in the following way:

  1. A new widget is downloaded
  2. The application contains at least one digital signature file containing signatures of all files in the downloaded application which are not themselves signature files (WidgetSignatures). The widget will also contain a manifest.
  3. Signatures are verified against the signing key and content of the widget, as per (WidgetSignatures).
  4. Webinos will check to see which of the signing authorities that were used to sign the application have certificates with roots in those installed in the platform.
  5. The user will be informed if none of the signing authorities are trusted by the platform and advised not to use the application. A policy MAY exist preventing the installation of such an application.
  6. Standard widget security and privacy control checks and authorisation. These include:
    1. Checking the policy.xml to see if the action of installing this widget is permitted.
    2. Prompting the user that installation of the widget will take place
    3. Showing the user the permissions requested (defined in "feature" tags) and allowing them to make changes to these permissions.
    4. Adding the widget to the list of 'installed applications' stored by the PZP
    5. Adding the widget code to the file system in the pre-defined location
    6. Creating policy rules defining the permissions this widget is allowed to have

An example UI is shown below. This is not implemented but explains the expectation for how an install screen might look.

The above image is not normative: it describes a potential UI but conforming implementations of this specification may have different UIs.

Each permissions will be displayed under the API requested. The text below each API will be machine-generated based on the features requested (e.g. which File permission - read or write) and the obligations and data handling policy defined in the "Privacy Policy" section of the webinos specifications.

The install screen UI shall by default only display features being requested by applications.

The default setting for permission requests shall be set based on a configuration file on the local platform - default_permission_settings.xml. This configuration file will have the same format as the access control policies, but is only processed to set defaults for the installation screen. If there is a conflict between the @<feature>@s requested by an application and the default permissions, defined as where default permissions state 'denied' but the feature is requested, this shall be flagged visually by the installation GUI. The installer may set the default (in this instance) to an ask-at-runtime prompt. The aim is that, should user 'click through' without changing anything on this form, the application will receive the default permissions defined by the platform rather than those requested by the application.

The result of the install screen UI will be additional XACML policies stored in the policy.xml file.

Applications may refer to remote content, such as through importing javascript in <script src="" /> statements. This is a potential attack vector unless the content is accessed securely and is served from the recognised origin or an origin defined in WARP. The script "src" must point to a https location, with certificate trusted by the webinos runtime. A script being loaded from other locations will not be allowed.

All applications must have signed manifests, but they may be signed by keys with self-signed certificates. User policies will dictate whether this is supported by the runtime. The PZP must store the association between the application and its certificate, and a different self-signed certificate cannot be used for subsequent versions of the application.

2.2 First use of a browser-based application

Browser-based applications can access webinos IF they are served from an origin with scheme HTTPS and IF the user 'installs' them. The installation process will be triggered by the web application attempting to use webinos APIs for the first time. When this happens, the application will create a WebSocket request to the PZP and pass with it the origin of the application. This is in accordance with the WebSocket specifications. The origin is the identity of the application and must be stored by the webinos runtime and used in webinos policies.

If the user does not install the web application, subsequent attempts to use webinos will be ignored. The decision to not install a web application therefore effectively blacklists it. This decision must be revocable through a PZP-provided UI.

When the PZP receives the origin of the application it MAY attempt to check the validity of the certificate of that domain to check that the certificate is trusted by a set of root authorities installed in the PZP, which are likely to mirror those in the browser.

Upon installation, the webinos platform shall create a new set of policies based on the recommendations outlined in the Security Framework for the application type. A prompt shall appear showing this information to the end user, as defined in the policy specification (Policy). This prompt will allow such a policy to be edited in some respects.

2.3 Implications of application installation

Installing and application - based on a browser or widget runtime - implies that the entire personal zone may be aware that the application has been installed. As per the policy specifications, installation of an application will result in the synchronisation of application manifests and policies to all personal zone devices.

3 Update of applications and application signatures

Widgets can be updated by following proposals described in the W3C Widget Update Working Draft (WidgetUpdates). Remotely hosted content loaded by a widget and browser-based applications require no special mechanism to be updated.

4 Revocation and management of application signatures

The webinos application security framework relies upon valid certificates being used and the webinos runtime containing a set of trusted certificates, much like a web browser. Webinos must periodically (as well as when the certificate is first installed) check each certificate is valid, and use OCSP to check that it has not been revoked. This task should be performed to the PZH, which can make the necessary updates and synchronise them between all user devices.

5 Application communication with the PZP

Webinos applications will communicate with the PZP in different ways depending on the application type and the platform.

Platform Browser-based applications Widgets
Android Web socket Android IPC
Windows Web socket Web socket
Linux Web socket TBC

All platforms will inject the webinos.js script in some way to allow applications to access webinos APIs.

5.1 WebSocket

The PZP will create a secure WebSocket server on localhost which should only accept connections from local entities.

The secure websocket server SHALL use the certificates defined in the Personal Zone Key Infrastructure documentation.

WebSockets SHALL request client certificates and SHALL reject unauthenticated connections. Each widget renderer SHALL therefore contain a valid certificate issued by the PZP. Installation of this certificate is a platform and renderer specific process.

5.2 Widget renderer communication

A widget renderer may communicate with the PZP through either the Web Socket mechanism given above, or through a native IPC mechanism. The IPC mechanism SHALL protect the integrity and confidentiality of communications and SHALL provide a means to authenticate the PZP and renderer.

6 Application communication with external services

Outside of webinos, application can communicate with external entities in a number of ways, including:

To avoid the security and privacy implications of some of these mechanisms, the following policies are used in widget renderers.

6.1 WARP restrictions

As described in the Widget Runtime section, widgets shall use the WARP specification to define the origins that a widget may access.

6.2 JavaScript restrictions

The webinos platform will follow most of the recommendations defined by Google Chrome Extensions (ChromeCSP) but dictate how this must be implemented.

  1. webinos applications will be disallowed from running inline JavaScript.
  2. JavaScript resources may only be loaded from local files included in the widget, locations from the widget's recognised origin, or from HTTPS origins defined in the WARP section of the manifest.
  3. String-to-JavaScript methods like eval() and function() are disabled.

6.3 Additional runtime restrictions

External pages (from origins not mentioned in the application's WARP configuration) may not be embedded in an iframe within the application. Images, video and audio may be referenced from any origin as normal.

A valid widget render will not enable extensions while webinos applications are running.

7 References

7.1 ChromeCSP

Google Chrome Extensions - Content Security Policy
Unknown author, Google
Fetched: August 2012

7.2 WAC

WAC Core Specification 2.1

Section 4: Security and Privacy
30 April 2012

7.3 WidgetSignatures

XML Digital Signatures for Widgets
W3C Proposed Recommendation 11 August 2011

743 WidgetUpdates

Widget Updates
W3C Working Draft 22 March 2012

7.5 Policy

Policy specifications