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.
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]
System applications have more privileges than normal web applications, including access to powerful system-level interfaces.
This section describes a number of mitigations that address the threats described in the previous section.
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.
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.
The runtime must provide each system application with isolated storage.
FIXME: Explain the security and privacy benefits of isolated storage.
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
When runing the steps for
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.
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.
'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
System applications may designate one or more resources as
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.
The runtime must prevent system applications from instantiating unsandboxed plug-ins. FIXME: What does "unsandboxed" mean?
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.
Thanks to ??? for their useful comments.