Security/Features/Sandboxing of content processes

From MozillaWiki
Jump to: navigation, search
Please use "Edit with form" above to edit this page.


Sandboxing of content processes
Stage Development
Status In progress
Release target `
Health Blocked
Status note Waiting on E10S enabled by default


Product manager Sid Stamm
Directly Responsible Individual Sid Stamm
Lead engineer Guillaume Destuynder
Security lead Guillaume Destuynder
Privacy lead `
Localization lead `
Accessibility lead `
QA lead `
UX lead `
Product marketing lead `
Operations lead `
Additional members Brian Bondy, David Keeler, Christoph Kerschbaumer

Open issues/risks

  • E10S is slow going, so only slow progress can be made
  • Threat model needed

Stage 1: Definition

1. Feature overview

Process isolation is designed to separate Firefox into multiple processes, each with the least amount of privilege necessary. In doing so, the potential damage for a large number of Firefox vulnerabilities can be reduced. While implementing sandboxing is not a goal for the current phase of Electrolysis, we need to consider the architectural requirements for doing so now in order to effectively support sandboxing in the future.

We will do so by:

  • identifying high level of categories of threats that we could address via process isolation
  • determining the architectural implications of mitigating each category
  • selecting a threat model and architecture that will address it, and prototyping it
  • determining whether the chosen model is actually feasible within the current Gecko architecture
  • implementation roadmap
  • implement it

2. Users & use cases

  • Reduce the damage for various types of vulnerabilities within Firefox. This is a defense in depth measure.

3. Dependencies

Older project description:
Early draft of threat model:

4. Requirements

  • Define a threat model
  • Verify whether the implementation effectively mitigates the threats


  • Eliminate security vulnerabilities. Sandboxing can reduce the severity of a given bug (by reducing the privilege the malicious code runs with), but it doesn't not actually prevent nor fix the underlying bug.

Stage 2: Design

5. Functional specification


6. User experience design


Stage 3: Planning

7. Implementation plan

  • Land libraries to support low-rights mode for proceses
  • Hook into e10s to begin lowering rights for content processes
  • Iteratively remove individual rights, fix regressions, repeat

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 Product Hardening
Roadmap Security
Secondary roadmap Platform
Feature list `
Project `
Engineering team Security

Team status notes

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

Chrome already does something similar. See

Microsoft also had a research project for a multi-principal browser: