B2G App Security Model
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
`
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, and on BrowserID as well.
4. Requirements
- An app store needs to be able to approve an application, implying they can verify the integrity and authenticity of the 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
- User needs to manage the permissions of the app throughout its lifecycle
- 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
`
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=` |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, and on BrowserID as well. |Feature requirements=*An app store needs to be able to approve an application, implying they can verify the integrity and authenticity of the 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
- User needs to manage the permissions of the app throughout its lifecycle
- 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=` |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=` }}