B2G App Security Model

Please use "Edit with form" above to edit this page.

Status

B2G App Security Model
Stage	Draft
Status	`
Release target	B2G 1.0
Health	OK
Status note	`

{{#set:Feature name=B2G App Security Model

|Feature stage=Draft |Feature status=` |Feature version=B2G 1.0 |Feature health=OK |Feature status note=` }}

Team

Product manager	Lucas Adamski
Directly Responsible Individual	Chris Jones
Lead engineer	`
Security lead	Paul Theriault
Privacy lead	`
Localization lead	`
Accessibility lead	`
QA lead	`
UX lead	`
Product marketing lead	`
Operations lead	`
Additional members	`

{{#set:Feature product manager=Lucas Adamski

|Feature feature manager=Chris Jones |Feature lead engineer=` |Feature security lead=Paul Theriault |Feature privacy lead=` |Feature localization lead=` |Feature accessibility lead=` |Feature qa lead=` |Feature ux lead=` |Feature product marketing lead=` |Feature operations lead=` |Feature additional members=` }}

Open issues/risks

Will B2G have an "installed apps" mechanism for installing static offline applications, or will all apps be loaded over the web (using Offline Web Application API as necessary for offline mode)?

Will applications need to be signed? (if so how, and what will be signed?)

Stage 1: Definition

1. Feature overview

The B2G app security model governs how applications are discovered, installed, managed, run and updated.

This feature page is tracking these requirements independently of the general Mozilla Open Web Apps security model even though we expect the models to be compatible, since B2G has specific issues that need to be considered in addition to browser-hosted applications.

2. Users & use cases

Users may obtain apps from a Mozilla application store, vendor or carrier application store, or other 3rd party stores. Some of these apps may have special privileges (such as a phone dialer) that may require additional controls.

Users should be able to discover, installed, run, update and uninstall application as they see fit. These applications should be able to run offline. Users should also be able to manage the security and privacy relevant settings for those applications, potentially at different phases of the apps lifecycle (at install, at runtime, independently).

3. Dependencies

Heavily dependent on the Open Web Apps security model and ecosystem (including Marketplace), and on BrowserID as well.

4. Requirements

• An app store needs to be able to approve an application, implying they can verify the permissions, integrity and authenticity of the app
• App store needs to be able to revoke an app
• A user needs to be able to make a trust decision at install time, so they also need to be able to verify the authenticity, integrity and privileges of an app
• An store app must be able to set the default permissions for an app
• User has control of the permissions of the app throughout its lifecycle, overriding those set by the app store if desired
• Apps should be able to discover their privileges and degrade gracefully in a limited privilege environment
• Permissions need to be expressed to the user in a way that they can realistically be expected to comprehend (perhaps with options for power-users)
• Permissions requested / set need to be enforced.
• Apps should not be vulnerable to common web vulnerabilities when granted significant privileges
• Ability to grant trust for certain highly sensitive privileges (such as phone dialing) may be restricted at the OS level to specific trusted parties

Non-goals

This document does not try to define the broader B2G security model, nor does it define the Open Web Apps security model even though we expect that B2G will contain a superset of the latter's requirements.

Stage 2: Design

5. Functional specification

A threat model is being documented here: https://wiki.mozilla.org/B2G_App_Security_Model/Threat_Model

WebAPI permissions manager implementation: https://bugzilla.mozilla.org/show_bug.cgi?id=707625

6. User experience design

`

Stage 3: Planning

7. Implementation plan

`

8. Reviews

Security review

`

Privacy review

`

Localization review

`

Accessibility

`

Quality Assurance review

`

Operations review

`

Stage 4: Development

9. Implementation

`

Stage 5: Release

10. Landing criteria

` {{#set:Feature open issues and risks=Will B2G have an "installed apps" mechanism for installing static offline applications, or will all apps be loaded over the web (using Offline Web Application API as necessary for offline mode)?

Will applications need to be signed? (if so how, and what will be signed?) |Feature overview=The B2G app security model governs how applications are discovered, installed, managed, run and updated.

This feature page is tracking these requirements independently of the general Mozilla Open Web Apps security model even though we expect the models to be compatible, since B2G has specific issues that need to be considered in addition to browser-hosted applications. |Feature users and use cases=Users may obtain apps from a Mozilla application store, vendor or carrier application store, or other 3rd party stores. Some of these apps may have special privileges (such as a phone dialer) that may require additional controls.

Users should be able to discover, installed, run, update and uninstall application as they see fit. These applications should be able to run offline. Users should also be able to manage the security and privacy relevant settings for those applications, potentially at different phases of the apps lifecycle (at install, at runtime, independently). |Feature dependencies=Heavily dependent on the Open Web Apps security model and ecosystem (including Marketplace), and on BrowserID as well. |Feature requirements=*An app store needs to be able to approve an application, implying they can verify the permissions, integrity and authenticity of the app

• App store needs to be able to revoke an app
• A user needs to be able to make a trust decision at install time, so they also need to be able to verify the authenticity, integrity and privileges of an app
• An store app must be able to set the default permissions for an app
• User has control of the permissions of the app throughout its lifecycle, overriding those set by the app store if desired
• Apps should be able to discover their privileges and degrade gracefully in a limited privilege environment
• Permissions need to be expressed to the user in a way that they can realistically be expected to comprehend (perhaps with options for power-users)
• Permissions requested / set need to be enforced.
• Apps should not be vulnerable to common web vulnerabilities when granted significant privileges
• Ability to grant trust for certain highly sensitive privileges (such as phone dialing) may be restricted at the OS level to specific trusted parties

|Feature non-goals=This document does not try to define the broader B2G security model, nor does it define the Open Web Apps security model even though we expect that B2G will contain a superset of the latter's requirements. |Feature functional spec=A threat model is being documented here: https://wiki.mozilla.org/B2G_App_Security_Model/Threat_Model

WebAPI permissions manager implementation: https://bugzilla.mozilla.org/show_bug.cgi?id=707625 |Feature ux design=` |Feature implementation plan=` |Feature security review=` |Feature privacy review=` |Feature localization review=` |Feature accessibility review=` |Feature qa review=` |Feature operations review=` |Feature implementation notes=` |Feature landing criteria=` }}

Feature details

Priority	P1
Rank	999
Theme / Goal	`
Roadmap	Security
Secondary roadmap	Gecko
Feature list	`
Project	`
Engineering team	`

{{#set:Feature priority=P1

|Feature rank=999 |Feature theme=` |Feature roadmap=Security |Feature secondary roadmap=Gecko |Feature list=` |Feature project=` |Feature engineering team=` }}

Team status notes

	status	notes
Products	`	`
Engineering	`	`
Security	`	`
Privacy	`	`
Localization	`	`
Accessibility	`	`
Quality assurance	`	`
User experience	`	`
Product marketing	`	`
Operations	`	`

{{#set:Feature products status=`

|Feature products notes=` |Feature engineering status=` |Feature engineering notes=` |Feature security status=` |Feature security health=` |Feature security notes=` |Feature privacy status=` |Feature privacy notes=` |Feature localization status=` |Feature localization notes=` |Feature accessibility status=` |Feature accessibility notes=` |Feature qa status=` |Feature qa notes=` |Feature ux status=` |Feature ux notes=` |Feature product marketing status=` |Feature product marketing notes=` |Feature operations status=` |Feature operations notes=` }}