@@ -121,12 +123,9 @@ The security requirements are primarily concerned with ensuring the safe use of
The browser MUST NOT write any information that is derived from or that reveals browsing activity to the disk, or store it in memory beyond the duration of one browsing session, unless the user has explicitly opted to store their browsing history information to disk.
4. ~[Application Data Isolation](#44-application-data-isolation)~
~The components involved in providing private browsing MUST be self-contained, or MUST provide a mechanism for rapid, complete removal of all evidence of the use of the mode. In other words, the browser MUST NOT write or cause the operating system to write any information about the use of private browsing to disk outside of the application's control. The user must be able to ensure that secure deletion of the software is sufficient to remove evidence of the use of the software. All exceptions and shortcomings due to operating system behavior MUST be wiped by an uninstaller. However, due to permissions issues with access to swap, implementations MAY choose to leave it out of scope, and/or leave it to the operating system/platform to implement ephemeral-keyed encrypted swap.~
`this section should be removed and we need to redirect users who need such protections to Tails`
4.[Least Privilege](#44-least-privilege)
The browser MUST NOT run with permissions or capabilities it does not need to function.
### 2.2 Privacy Requirements
...
...
@@ -168,8 +167,6 @@ In addition to the above design requirements, the technology decisions about the
~Therefore, if plugins are to be enabled in private browsing modes, they must be restricted from running automatically on every page (via click-to-play placeholders), and/or be sandboxed to restrict the types of system calls they can execute. If the user agent allows the user to craft an exemption to allow a plugin to be used automatically, it must only apply to the top level URL bar domain, and not to all sites, to reduce cross-origin fingerprinting linkability.~
`
4.**Minimize Global Privacy Options**
[Another failure of Torbutton](https://gitlab.torproject.org/legacy/trac/-/issues/3100) was the options panel. Each option that detectably alters browser behavior can be used as a fingerprinting tool. Similarly, all extensions [should be disabled in the mode](https://blog.chromium.org/2010/06/extensions-in-incognito.html) except as an opt-in basis. We should not load system-wide and/or operating system provided addons or plugins.
...
...
@@ -198,6 +195,26 @@ In addition to the above design requirements, the technology decisions about the
We believe that if we do not stay current with the support of new web technologies, we cannot hope to substantially influence or be involved in their proper deployment or privacy realization. However, we will likely disable high-risk features pending analysis, audit, and mitigation.
### 2.4 Limitations
In the past, we have made [application data isolation](https://2019.www.torproject.org/projects/torbrowser/design/#app-data-isolation) an explicit goal, whereby all evidence of the existence Tor Browser usage can be removed via secure deletion of the installation folder.
The majority of deployed Tor Browser installs run on platforms which either explicitly disrespect user agency and privacy (for-profit platforms such as Android, macOS, and Windows) or whose threat model may be less extreme than that of some of our users (the various flavours of Linux and BSD).
Developing real application data isolation with enough certainty that we could confidently promise to our users that it works would be an astronomical undertaking. It would require a never ending auditing process to identify all of the conditions under which the operating itself leaks information about the user's browsing session. We would need to modify the browser to either work around the data-leaking API calls or implement cleanup functionality for each platform to wipe the offending data from disk. We would need testing infrastructure to ensure we did not have regressions on these platforms.
This work would need to be done for each of our four supported operating systems, each of which has multiple supported CPU architectures, untold number of major+minor versions, and various hardware-vendor customisations. This is not achievable in the general case, and we should not pretend that it is.
Suppose the above *were* possible, and that we could somehow know with certainty every condition under which the operating system leaks session data to disk. Even if we had such an acolyte with perfect knowledge, we would still have a big problem with no viable solution.
The operating system necessarily runs at a higher level of privilege and power than Tor Browser does. This means the operating system has a higher level of access to the rest of the system, meaning it can store things in places the browser process does not have access to.
For example, on Windows it is a common design pattern for user-space platform API calls to be routed to and implemented in service processes running as `SYSTEM` or `Administrator` (which are similar to root on Linux) via RPC mechanisms. These services can write whatever they like to the `HKLM` registry hive, whereas the browser cannot; it does not have the required privileges.
In order to remove a leak to `HKLM` or other similar data-stores, the browser *itself* would need the capability to elevate itself to the same level of permissions as the process which leaked in the first place. Such a capability would work directly against our [least privilege](#44-least-privilege) security requirement and could negate the entire browser sandboxing efforts of the past few decades which (mostly) ensures 0-day exploits do not take over your system when watching cat videos on the internet.
We would direct users who *do* have disk forensics in their threat model to the [Tails operating system](https://tails.net/). Tails is a purpose-built Linux-based operating system which is ephemeral by default, and also supports full-disk encryption for persistent storage if needed. It essentially provides whole operating system level data isolation to its users with a level of confidence unachievable for Tor Browser on its own.
## 3. Adversary Model
A Tor web browser adversary has a number of goals, capabilities, and attack types that can be used to illustrate the design requirements for the browser. Let's start with the goals.
...
...
@@ -388,13 +405,13 @@ As an additional defense-in-depth measure, we set `browser.cache.disk.enable`, `
For more details on disk leak bugs and enhancements, see the [Disk Leak](https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/?sort=updated_desc&state=opened&label_name%5B%5D=Disk%20Leak&first_page_size=20) tag in our issue tracker.
### ~4.4 Application Data Isolation~
### 4.4 Least Privilege
~The browser MUST NOT cause any information to be written outside of the bundle directory. This is to ensure that the user is able to completely and safely remove it without leaving other traces of Tor usage on their computer.~
**Design Goal**: The browser MUST run with as few permissions and capabilities as possible to function.
~To ensure browser directory isolation, we set `browser.download.useDownloadDir`, `browser.shell.checkDefaultBrowser`, and `browser.download.manager.addToRecentDocs`. We also set the `$HOME` environment variable to be the browser extraction directory.~
**Implementation Status**: Tor Browser inherits Firefox ESR's upstream sandboxing protections. Tor Browser for Android disables some additional platform permissions related to telemetry and advertising, which are of course not needed.
`purge purge`
On Windows, the browser installer does not require Administrator privileges to run. We additionally have patched Tor Browser's updater to remove the code-paths which could trigger elevated execution on Windows.
