B2G App Security Model

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


B2G App Security and Privacy Model
Stage Complete
Status Complete
Release target B2G 1.0
Health OK
Status note `


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

Open issues/risks

What unique types of apps do we support (local installed with special privileges, local installed with normal privileges, remotely hosted but locally installed, remote apps within browser)?

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)?

How should apps with "special" privileges be managed (identified, discovered, installed, updated)? Do they require a different security model?

What restrictions should exist for code and content importing for apps (remote to local, cross-domain)?

Which types of applications need to be signed? (if so how, and what will be signed?)

How does an app store blacklist / revoke an application?

Should permission requests/notifications happen at install time, at runtime, or both?

Should permissions be opt-in or opt-out?

Should apps be notified when permissions are denied for a given app, or should permission failures be indistinguishable from other failure modes?

Exploit mitigations for in-content attacks (i.e. code injection, MITM)

Exploit mitigations for memory-safety attacks (multi-process with restricted rights for app processes)

User control: Can the user always override the permission settings for an app?

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 number of different stores, including 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 or extra authentication.

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
  • App store must be able to set the default permissions for 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
  • 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



Stage 2: Design

5. Functional specification

The current state of the application security model is located here: Apps/Security

A threat model is being documented here: B2G_App_Security_Model/Threat_Model

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

Design Decisions Made

  • One app per origin (FQDN) where app URL may potentially be a new URI type
  • Multiple App stores
  • Apps are peers to their native equivalents from an experience standpoint
  • Four types of web applications

6. User experience design


Stage 3: Planning

7. Implementation plan


8. Reviews

Security review


Privacy review


Localization review




Quality Assurance review


Operations review


Stage 4: Development

9. Implementation


Stage 5: Release

10. Landing criteria


Feature details

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

Team status notes

  status notes
Products ` `
Engineering ` `
Security sec-review-needed bug 744915
Privacy ` `
Localization ` `
Accessibility ` `
Quality assurance ` `
User experience ` `
Product marketing ` `
Operations ` `