Runtime and Security Model for Web Applications

2.1.1 Adding new properties to the manifest

Any new specification can add new properties to the application manifest. Those specifications MUST describe the new properties, the expected values and the expected behaviour. Implementations MUST implement the basic properties as describe below but SHOULD only implement any extented feature if they are implementing those specifications.

2.1.2 Basic properties

All leaf properties MUST contain a string value unless specified otherwise.

The following properties MUST be part of the application manifest: name and description. In addition, if locales is part of the application manifest, default_locale MUST be part of the application manifest. The other properties are optional.

• name: The name of the web application in the default locale. The name SHOULD not be longer than 128 characters.
• description: A short description of the web application. The description MUST be in the default locale. The description SHOULD not be longer than 1024 characters.
• default_locale: The property's value MUST be the top-level name and description's locale.
• launch_path: The property's value MUST be the path within the application's origin that is loaded when the application is launched.
• icons: A map of icon sizes to URIs of the icons (which may be absolute, relative or data URIs). Icons MUST be square. Relative URLs MUST use the application manifest URL as base URL.
• developer: This property describe the developer of the application and MUST contain the following properties:
  • name: The value MUST contain the name of the developer.
  • url: The value MUST contain an URL pointing to the developer's website
• locales: The property's value MUST contain a map of locale specific overrides of strings contained in the application manifest. Each locale key is keyed on a locale tag [RFC4646], and contains a sparse representation of the manifest. Any field in the locales property SHOULD override the corresponding property in a localized user interface. The UA MAY ignore some values if localizing the property doesn't appear to be legit.
  If the locales property is set, the default_locale MUST also be set.
• appcache_path: The value MUST contain the absolute path to the application cache manifest [OFFLINE-WEBAPPS].
  When an application is installed, the AppCache manifest will be fetched and parsed, and its static assets under the CACHE header MUST be cached.
• version: The value MUST be a string that represents the version of the application. The UA SHOULD NOT interpret this value but MAY show it to the user so the auther SHOULD use human understandable versions.
• screen_size: This object SHOULD contain the min_height and min_width properties that describe the minimum height and width (in pixels) the application needs in order to render correctly. Those values are only hint for the UA and should not be considered as mandatory restrictions.
• required_features: This value MUST be an array containing the mandatory feature set the application needs in order to run correctly. If the property is missing or the value is an empty array or if the value is invalid, the mandatory feature set SHOULD be considered as the empty set.
  TBD: add a list of features.
• fullscreen: This value MUST be set to either true or false to describe whether the runtime should launch the application in fullscreen mode.
• relNotes: This property's value MUST contain a map associating an application's version with a string describing the changes between that version and the previous one.
• permissions: This value consists of a set of permissions that the application needs. An application SHOULD list every API that is considered to require user permission in this field. Usage of an API without a corresponding entry in the manifest SHOULD fail. The field is an object, with each property name specifying a single permission, and object containing the following fields:
  • description: Contains a human readable string specifying the intent behind requesting use of this API. This property is mandatory.
  • access: Contains a a string specifying the type of access required for this permission. This field is mandatory for a certain subset of permissions, and MUST be one of read, readwrite, readcreate, or createonly.

  Each specification MUST specify the new permissions that would be required to use the feature it is defining.

The application's origin is the origin of the application manifest. [ORIGIN]

Web Applications are represented by the Application interface.

interface Application {
    readonly    attribute DOMString     origin;
    readonly    attribute Object        manifest;
    readonly    attribute DOMString     installOrigin;
    readonly    attribute unsigned long installTime;
    readonly    attribute Object        parameters;
    DOMRequest      launch ();
    DOMRequest      uninstall ();
    readonly    attribute DOMString     updateState;
    readonly    attribute unsigned long downloadSize;
    DownloadRequest downloadUpdate ();
    readonly    attribute DOMString     state;;
    void            hide ();
    void            exit ();
                attribute EventHandler  onlaunch;
                attribute EventHandler  onpause;
                attribute EventHandler  onresume;
                attribute EventHandler  onterminate;
};

interface DownloadRequest : DOMRequest {
    void cancel ();
                attribute double       progress;
                attribute EventHandler onprogress;
};

When the caller start the download, the DownloadRequest SHOULD start downloading the resource.

If the resource fails to download, the UA MUST send an error message to the request.

If the resource succeed to download, the UA MUST send a success message to the request.

While the resource is downloading, which means as long as readyState is pending, the UA SHOULD regularly fire a simple event named progress on the object. The UA should note that sending too much events might have an impact on performance but sending too few of them might impact the user experince.

The following are the event handlers (and their corresponding event handler event types) that MUST be supported as attributes by the DOMRequest objects:

An ApplicationRegistry instance is exposed on the Navigator object trough the an app attribute.

partial interface Navigator {
    readonly    attribute ApplicationRegistry app;
};

The ApplicationRegistry interface allows handling applications and query there status.

interface ApplicationRegistry {
    DOMRequest install (DOMString manifestUrl, [Optional] Object parameters);
    DOMRequest getSelf ();
    DOMRequest getInstalled ();
    DOMRequest checkInstalled (DOMString manifestURL);
                attribute ApplicationManagement management;
};

The ApplicationManagement interface allows access to all applications and is being informed any time an application is being installed or uninstalled. The intent of this interface is to be restricted to privileged callers.

interface ApplicationManagement {
    DOMRequest getAll ();
    [TreatNonCallableAsNull]
                attribute EventHandler oninstall;
    [TreatNonCallableAsNull]
                attribute EventHandler onuninstall;
    DOMRequest applyUpdate (Application application);
};

3.5.1 Events

An install event MUST be fired on all ApplicationManagement instances as soon as an application is installed.

The uninstall event MUST be fired on all ApplicationManagement instances as soon as an application is uninstalled.

The following are the event handlers (and their corresponding event handler event types) that MUST be supported as attributes by the ApplicationManagement object:

[Constructor(DOMString type, Application eventInitDict)]
interface ApplicationEvent : Event {
    readonly    attribute Application application;
};

dictionary ApplicationEventInit : EventInit {
    Application application;
};

callback systemMessageCallback = void (optional Object message);

partial interface Navigator {
    void    setMessageHandler (DOMString type, systemMessageCallback? callback);
    boolean hasPendingMessages (DOMString type);
};

9.4.2 Chain of trust

An application is said to be a trusted application if the origin installing the application is trusted by the UA and the origin installing the application consider the application as trusty.

A UA SHOULD have the public key of all installation origin it is considering trusted.

9.4.3 Marking an application trusted

A hosted application MUST be recognized as marked trusted by the installation origin if the application manifest is signed by the installation origin's private key.

A packaged application MUST be recognized as marked trusted by the installation origin if the package is signed by the installation origin's private key.

In both cases, the application SHOULD be considered as trusted by the UA if the UA considers the installation origin as trusted, following the chain of trust mentioned above.

9.4.5 CSP Policy

The following CSP policy MUST apply to all trusted applications [CSP]:

default-src *; script-src 'self'; object-src 'none'; style-src 'self'

This puts the following restrictions on web pages part of a trusted application:

• Scripts can only be loaded from the package;
• Scripts can not use data:-URIs;
• Inline scripts can not be used;
• eval() can not be used. Neither can eval-like functions like setTimeout or "new Function". setTimeout can still be used as long as the first argument is a Function object rather than a string;
• onXXX attributes can't be used in the markup of pages. However, using the associated EventHandler is doable. For example: myElement.onXXX = someFunction;
• <object>, <embed> and <applet> are fully disabled. In other words, plugins won't work at all. Including flash.
• CSS can only be loaded from the package. Inline CSS is however allowed.

This does not restrict any of the following:

• <iframe>s can still point to any URL;
• Images can still be loaded from anywhere. Including when loaded using an <img> element, when using CSS background images or when using other types of CSS images;
• Media (audio and video) can still be loaded from anywhere;
• Network connections can still be opened anywhere using data-centric APIs like XMLHttpRequest or WebSocket.

There is no way for trusted applications to relax this policy.