Security Model for System Application

Table of Contents

1. 1 Conformance
   1. 1.1 Dependencies
2. 2 Risks
3. 3 Mitigations
   1. 3.1 Installation
   2. 3.2 Uninstallation
   3. 3.3 Isolated Storage
   4. 3.4 Origin
   5. 3.5 Content Security Policy
   6. 3.6 Sandboxed Pages
   7. 3.7 Plug-ins
4. 4 Permission Model
5. References
6. Acknowledgments

1 Conformance

All diagrams, examples, and notes in this specification are non-normative, as are all sections explicitly marked non-normative. Everything else in this specification is normative.

The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this document are to be interpreted as described in RFC2119. For readability, these words do not appear in all uppercase letters in this specification. [RFC2119]

Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and terminate these steps") are to be interpreted with the meaning of the key word ("must", "should", "may", etc) used in introducing the algorithm.

Conformance requirements phrased as algorithms or specific steps may be implemented in any manner, so long as the end result is equivalent. (In particular, the algorithms defined in this specification are intended to be easy to follow, and not intended to be performant.)

User agents may impose implementation-specific limits on otherwise unconstrained inputs, e.g. to prevent denial of service attacks, to guard against running out of memory, or to work around platform-specific limitations.

When a method or an attribute is said to call another method or attribute, the user agent must invoke its internal API for that attribute or method so that e.g. the author can't change the behavior by overriding attributes or methods with custom properties or functions in ECMAScript.

Unless otherwise stated, string comparisons are done in a case-sensitive manner.

1.1 Dependencies

The IDL fragments in this specification must be interpreted as required for conforming IDL fragments, as described in the Web IDL specification. [WEBIDL]

Some of the terms used in this specification are defined in Web IDL. [WEBIDL]

2 Risks

System applications have more privileges than normal web applications, including access to powerful system-level interfaces.

Cross-site scripting

If a system application contains a cross-site scripting vulnerability, an attacker might be able to inject script into the application and abuse its privileges to access powerful system-level interfaces.

Honest-but-curious applications

Even well-meaning application developers can be tempted to misuse powerful interfaces. For example, an application developer might be tempted to misuse the user's contacts list or violate the user's privacy.

Malicious applications

Attackers might create malicious applications that attempt to harm the user.

3 Mitigations

This section describes a number of mitigations that address the threats described in the previous section.

3.1 Installation

By default, the runtime must not run applications that are not installed. Requiring a trust gesture before running applications lets the user control which applications will receive privileges from the runtime.

The runtime vendor may preinstall system applications that the vendor has verified are safe.

3.2 Uninstallation

The runtime must let the user uninstall system applications that were installed by the user. The runtime should let the user uninstall system applications that were preinstalled unless unintalling such an application would render the device unusable.

The runtime must not grant a system application a privilege that could be used to circumvent the install process.

Preventing system applications from gaining privileges that could be used to circumvent the uninstall process helps prevent system applications from becoming persistent malware. If an application misbehaves, the user has the option to uninstall the application and prevent further harm.

3.3 Isolated Storage

The runtime must provide each system application with isolated storage.

FIXME: Explain the security and privacy benefits of isolated storage.

3.4 Origin

The runtime must execute each system application in an origin distinct from all other system applications and web sites. For example, the runtime could assign each system application a unique identifier and use the origin system-application://unique identifier.

When runing the steps for XMLHttpRequest's send() method, the runtime must act as if the XMLHttpRequest origin and the request URL are same origin.

In a web application, granting an origin permission to issue same-origin XMLHttpRequests for every URL is very dangerous because those requests carry cookies and other credentials. This risk is largely mitigated in system applications because each system application runs with isolated storage. Even if a user has logged into their bank in their browser, the HTTP requests issued by system applications will not have the user's credentials and will not be associated with the user's banking session.

3.5 Content Security Policy

System applications use Content Security Policy [CSP] to help mitigate cross-site scripting. The runtime must enforce the following default CSP policy on resources contained in system applications:

default-src 'self';
connect-src *; 
style-src 'self' data: blob: filesystem: 'unsafe-inline';
img-src 'self' data: blob: filesystem:;
media-src 'self' data: blob: filesystem:;
frame-src 'self' data: blob: filesystem:;
font-src 'self' data: blob: filesystem:;

Implementations may add implementation-specific sources to the above policy as long as the user agent can verify the integrity of the resources retrieved from those sources.

By omitting 'unsafe-inline' and 'unsafe-eval' from the script-src directive, the policy blocks inline scripts, which are a common source of cross-site scripting vulnerabilities. By omitting insecure sources, the policy prevents system applications from mixing insecure content with secure content.

FIXME: Explain connection with the "offline first" design principle and the XMLHttpRequest/responseBlob pattern.

3.6 Sandboxed Pages

System applications may designate one or more resources as sandboxed pages and associate a sandboxing flag set, expressed as a list of sandbox directives. The application must not include the allow-same-origin, allow-top-navigation, or allow-popups directives.

If a resource has associated list of sandbox directives directives, the runtime must enforce the CSP policy sandbox directives instead of the default CSP policy.

3.7 Plug-ins

The runtime must prevent system applications from instantiating unsandboxed plug-ins. FIXME: What does "unsandboxed" mean?

4 Permission Model

Interfaces for system application can be associated with one or more permissions, which are strings. FIXME: Fill in a description of how the permissions model works.

References

Acknowledgments

Thanks to ??? for their useful comments.