How Project Fission Implements Site Isolation in Firefox

Project Fission is a major architectural overhaul of the Mozilla Firefox web browser designed to enforce strict site isolation. This article provides an overview of how Fission secures user data and improves browser stability by separating different websites and cross-origin frames into their own dedicated operating system processes, effectively neutralizing memory-based side-channel attacks and containing browser crashes.

Moving Beyond Shared Content Processes

Before Project Fission, Firefox used a multi-process architecture called Electrolysis. This model separated the browser's user interface from web content using a fixed pool of content processes. While this improved performance, it meant that multiple unrelated websites often shared the same operating system process and, consequently, the same memory space.

Following the discovery of speculative execution CPU vulnerabilities like Spectre and Meltdown, sharing memory spaces became a severe security risk. A malicious website could use side-channel attacks to read sensitive data from another website residing in the same process. Project Fission solves this by abandoning the fixed-pool model and ensuring different sites never share the same operating system memory space.

Process Allocation by Site (eTLD+1)

Project Fission enforces isolation by assigning processes based on a website's "site" classification. In this architecture, a site is defined by its scheme (such as HTTP or HTTPS) and its effective Top-Level Domain plus one label (eTLD+1).

When you navigate the web in Firefox, the browser evaluates the eTLD+1 of the destination:

• Subdomains like https://mail.example.com and https://docs.example.com share the same site definition (https://example.com) and are allowed to run within the same operating system process.
• Completely different domains, such as https://example.com and https://bank.com, are strictly separated into distinct operating system processes.

Because the underlying operating system enforces strict hardware-level memory boundaries between separate processes, one process cannot read or manipulate the memory of another.

Out-of-Process Iframes (OOPIFs)

Modern webpages are rarely built from a single source; they frequently embed third-party content using inline frames (iframes) for advertisements, social media widgets, video players, and payment processors. Isolating only the top-level website is not enough to achieve strict site isolation.

Project Fission introduces Out-of-Process Iframes (OOPIFs). When a primary webpage loads an iframe hosted by a different site, Firefox automatically creates a separate operating system process specifically for that iframe. If a single webpage contains three third-party advertisements from three different ad networks, Firefox will use at least four processes to run that single tab: one for the main page, and one for each distinct ad network. If an embedded third-party iframe crashes or contains malicious code, the parent webpage remains unaffected and secure.

Inter-Process Communication and Sandboxing

Splitting a single webpage across multiple operating system processes requires a restructuring of how the browser manages data. Under Project Fission, individual content processes are heavily sandboxed. They have no direct access to the operating system's files, networks, or other content processes.

Instead, Firefox uses a privileged main process (the parent process) to act as a central broker. All isolated site processes must communicate with the parent process using Inter-Process Communication (IPC). If a webpage needs to interact with a cross-origin iframe via valid web APIs (like postMessage), the data is serialized, sent to the parent process via IPC, validated, and then routed to the target iframe's isolated process.

Coordinated Rendering and Input Routing

Even though a webpage and its iframes are split into separate processes, they must appear as a single, cohesive document to the user. Project Fission achieves this by changing how graphics and user inputs are handled:

• Visual Compositing: Firefox relies on its GPU-based compositor, WebRender. Each isolated content process independently generates a display list—a set of instructions on how to draw its specific part of the webpage—and sends it to the compositor process. The compositor then stitches the main page and all out-of-process iframes together into a single image on the screen.
• Input Routing: When a user clicks the mouse or scrolls on a webpage, the parent process intercepts the action first. Using the layout data provided by the compositor, the parent process calculates exactly which element on the screen was targeted and routes the input event directly to the specific operating system process responsible for rendering that exact pixel area.