Project Fission in Firefox: Origin Isolation With Process Budgeting

A single bad tab used to be able to take down a whole browser session, and a compromised renderer could read memory left by another site loaded in the same process. That is the concrete problem Project Fission was built to reduce: cross-origin data exposure inside a shared renderer.

The useful takeaway is that Firefox does isolate by origin, but it does not isolate everything all the time. Isolation is paired with heuristics and process limits so memory and startup cost stay manageable on real hardware.

What Fission isolates and why it matters

Project Fission is Firefox's implementation of site isolation. An origin is scheme + host + port, e.g., https://example.com:443. Fission aims to place each top-level site in its own content process where possible, limiting what a renderer compromise or a speculative execution side channel can reach.

A content process is the sandboxed process that runs web content for a set of tabs. The parent process coordinates UI, networking and IPC. Isolating origins means a third-party iframe from origin A cannot trivially access memory belonging to origin B because they run in different processes with separate address spaces.

Isolation also improves crash containment. A renderer crash in one content process tears down only the tabs hosted in that process, not unrelated tabs.

How Firefox controls the cost of isolation

Full per-tab isolation would be expensive. Firefox uses heuristics to reuse processes for same-origin navigations and to cap the total number of content processes.

High-risk sites are preferred for isolation. Same-site navigations may reuse an existing content process. Subframes are handled with additional heuristics rather than a strict one-frame-one-process rule.

These decisions are version-sensitive. Enterprise policies and about:config preferences can change autostart and limits. Changing those preferences can reduce security or increase memory use.

Seeing isolation in practice

A practical way to reason about Fission is with two different e-commerce sites open in separate tabs. Under normal heuristics each top-level origin tends to get its own content process. A compromised third-party iframe loaded in one tab is confined to that process and cannot directly access memory of the other tab's process.

Storage partitioning under Enhanced Tracking Protection works alongside process boundaries. Per-site data is kept separate, which reduces cross-site tracking via storage.

Verify isolation on your build

Verification is manual and version-dependent. On a desktop Firefox build, open about:support in the address bar. Look for the Multiprocess Windows and Isolated Web Content sections to see whether multiprocess and isolation are reported as enabled and how many content processes are active.

about:config can be used to confirm the feature flag state. Open about:config and search for fission.autostart. Changing this preference requires restart and reduces security if disabled. Do not change preferences unless you understand the risk.

about:processes shows live content processes per tab and origin. It is useful for a diagnostic decision: if two different origins appear under the same content process, that is expected for same-site reuse or when process limits are hit.

Trade-offs and limitations

More isolated processes means more memory. On low-memory devices the process budget can cause reuse that weakens isolation guarantees. Isolation level and process count vary by Firefox version and platform.

Not all content is isolated. Subframes and same-site navigations may share processes per heuristics. Isolation does not prevent all side channels, only those that rely on cross-origin memory access within a shared renderer.

Actionable check: open about:support and about:processes on the Firefox build you support, note the reported isolation state and process count, and document the version assumptions for your team. Treat any preference changes as security-relevant configuration.