We target Private Browsing to 3 privacy goals; in a Private Browsing session, Firefox:
- Doesn’t save the browsing history or display it in the Firefox UI
- Prevents the session's data from writing to persistent storage
- Protects the session's data from online tracking
The first 2 goals focus on a local adversary - someone with direct access to Firefox. Private Browsing was initially designed with just these two goals in mind. The initial design concentrated on isolating Private Browsing mode from regular browsing mode.
In 2015, we added Tracking Protection to Firefox to help protect users from online adversaries. In 2018, we officially added the 3rd goal to Private Browsing design scope.
To achieve all these goals, we concentrate on: local privacy, session isolation, and site isolation. We highlight these aspects in the goal descriptions below. (Note that a by-product of these protections allowed users to sign into a website with 2 accounts. A feature now better accomplished with the Multi-Account Containers add-on.)
We should not write any full or partial addresses or site data from Private Browsing page visits in a way that shows them in the local regular Firefox UI.
In the Firefox UI, the user ends their private session with a website when they close ALL their private windows. So, when the user closes the last private browsing window, we clear our in-memory caches of data from the sites the user visited. There is some mismatch between the user's mental model of individual private windows and this implementation. (e.g., Bug 1197159)
We should not write any full or partial addresses or site data from Private Browsing page visits in a way that shows them to local OS disk mechanisms. This means writing this information to a custom file or a SQLite database in the user's profile is not permitted.
We do not try to protect against all scenarios - e.g., attacking the disk-based page file used by the OS, or forensic analysis. We allow the OS to cache data from memory to disk, and we don't protect against runtime process memory probes.
We also treat some user actions as requests to persist website data, and write that data to the disk. For example, we save bookmarks from private windows. (Note: we save them as un-visited bookmarks.) We DO NOT save passwords entered into Private Browsing.
We isolate a website running in a normal window from itself running in a private window. We make it unable to share data between the 2 modes via the browser. E.g., we isolate a website's private cookies from its regular cookies. (Note that a by-product of this protection allows users to sign into a website with 2 accounts - a feature now better accomplished with the Multi-Account Containers add-on.)
- Is network level privacy a goal? Should private browsing use an anonymizing proxy?
- Research suggests users expect private browsing provides network level privacy. From a technical standpoint this is a challenging problem of its own, so we have not implemented it yet.
- What about add-ons?
- By default, Firefox add-ons request "spanning" access to Private Browsing but users must explicitly grant access to private windows. There is a bug to support all "incognito" key values, including "not_allowed". For add-ons distributed on AMO, reviewers look for proper use and treatment of private browsing mode.
- Does my feature have to respect private browsing?
- Most likely yes - please consider private browsing when designing and implementing your features. If you think your feature does not, please discuss with dev-privacy.
- Can an online adversary detect private browsing mode?
- From a purely technical standpoint, there are a few weak spots in the platform that make it impossible to hide private browsing mode effectively. Also, over the years, it has become even more difficult to protect from new threats (e.g., fingerprinting) AND hiding the protections themselves.