Some system-level applications require access to APIs which, if abused, may cause significant damage to the end user's services, data or devices. For example, an API allowing access to all installed applications could be misused by a malicious application to launch, install, or uninstall any application without user's consent.
Because the impact of using a malicious application with these privileges is higher, additional security mechanisms and processes are necessary to minimize the additional risk they present. This might include, for example, mandatory review of applications or certification. A simple user-authorized permission system is considered insufficient: users could be tricked into granting a malicious application access to inappropriate APIs, services or data.
As a complement to permissions [[!SYSAPPS-RUNTIME]], this specification defines a privileged application. Applications which are not privileged will not be able to access potentially dangerous APIs defined in this specification.
There is only one class of product that can claim conformance to this specification: a user agent.
The IDL fragments in this specification must be interpreted as required for conforming IDL fragments, as described in the Web IDL specification. [[!WEBIDL]].
The EventHandler interface represents a callback used for event handlers as defined in [[!HTML5]].
The concept of fire a simple event is defined in [[!HTML5]].
The terms event handlers and event handler event types are defined in [[!HTML5]].
The DOMError interface represents an error handling object as defined in [[!DOM4]].
The Application and DOMRequest interfaces are defined in [[!SYSAPPS-RUNTIME]].
An application is said to be a privileged application if the origin installing the application is trusted by the UA and the origin installing the application considers the application to be trustworthy.
A UA SHOULD have the public key of all installation origins it considers to be trusted.
A hosted application MUST be recognized as marked privileged 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 privileged 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 privileged by the UA if the UA considers the installation origin as trusted, following the chain of trust mentioned above.
UA should keep in mind that a signed package is way more secure than a signed manifest. A correctly signed package can only be compromised if the private key has been compromised or the cryptographic algorithm. A UA should not trust an installation origin if it does not trust its ability to keep safe its private key.
On the other hands, a signed manifest only proves that the application is genuinely trusted (if the private key was not compromised nor the cryptographic algorithm). Anything else can be compromised given that it lives in the Internet. There is no need to list all possible attacks.
An important difference between a packaged application and a hosted application is the ability to review the code. Any permission granted to a packaged application will be granted to the code inside the package only. That means trusting such application is way easier after a code review, for example.
However, code review for packaged applications could be avoided if the installation origin trusts enough an application developer. Such developer could get all its packaged applications trusted without too much risk for the users. The same thing could be done for hosted application except that it would be recommended to make sure that the developer has strong server security or would not risk any security flaw on their servers.
The following CSP policy for privileged applications MUST
apply to all privileged applications [[!CSP]]:
default-src *; script-src 'self'; object-src 'none';
style-src 'self'
This puts the following restrictions on web pages part of a privileged application:
This does not restrict any of the following:
There is no way for privileged applications to relax this policy.
An ApplicationManagement instance is exposed on the
ApplicationRegistry object through the
management attribute.
If the caller is not allowed to manage applications, the UA must return null. Otherwise, it MUST return an ApplicationManagement object.
The ApplicationManagement interface allows access to all applications and is being informed any time an application is being installed or uninstalled.
Move
Application.uninstall() and
Application.updateState to
ApplicationManagement; consider adding
an event handler for updateState.
The getAll method SHOULD return a DOMRequest
object and asynchronously get all installed applications.
When those applications are collected, the UA SHOULD send a
success event to the DOMRequest object and
populate its request attribute with an array of
Application objects representing the applications.
The applyUpdate method MUST return a DOMRequest
object and perform the following steps asynchronously:
InvalidState and abort these
steps.
Application object representing the updated
application as a value.
An install event using the ApplicationEvent interface
MUST be fired on all ApplicationManagement instances as soon
as an application is installed with the application
attribute set to the Application object representing the
installed application.
The uninstall event using the ApplicationEvent
interface MUST be fired on all ApplicationManagement
instances as soon as an application is uninstalled with the
application attribute set to the Application
object representing the uninstalled application.
The following are the event handlers (and their
corresponding event handler event types) that MUST be
supported as attributes by the ApplicationManagement
object:
| event handler | event handler event type |
|---|---|
oninstall
|
install
|
onuninstall
|
uninstall
|
Application events are sent when an event happen on the application level like an application being installed or uninstalled.
ApplicationEvent objects MUST contain a non-null
application attribute representing the application on
each the action happened. The application events are always sent
asynchronously, do not bubble and are not cancelable.
There are currently two types of application events:
application MUST represent the installed application.
application MUST represent the uninstalled
application.
Special thanks to the Mozilla team working on Open Web Apps, especially Anant Narayanan for his Web Application Manifest Format and Management APIs specification that this document reuse shamelessly and Fabrice Desré for his help in understanding why some decisions were made.
Special thanks to the Samsung team, especially 金明(Ming Jin), Janusz Majnert and 송정기(Jungkee Song) for their work on the System Application Runtime: Execution and Security Model specification.
Special thanks to Jonas Sicking and Marcos Caceres for their invaluable help.
Thanks to John Lyle, Christophe Dumez and Jonathan Jeon for their useful comments and change proposals.