Tor Browser is often described as “Firefox routed through Tor,” but that description is incomplete.
Its design is based on a broader security model in which the browser engine, Tor client, browser profile, anti-fingerprinting protections, privacy defaults, update mechanism, and runtime data are treated as parts of one controlled environment.
That design has several practical consequences on Linux. Installation differs from conventional browsers, profile handling is less flexible than Chromium-based browsers, and creating multiple isolated environments can result in multiple complete Tor Browser installations rather than several lightweight profiles.
This article explains how that architecture works on Arch Linux and why Tor Browser is designed this way.
Installing Tor Browser on Arch Linux
The standard Arch Linux approach is to install torbrowser-launcher:
sudo pacman -Syu torbrowser-launcher
Then start it with:
torbrowser-launcher
A crucial detail is that pacman does not install the complete Tor Browser bundle.
It installs the launcher:
/usr/bin/torbrowser-launcher
The launcher then performs several tasks:
Check the current Tor Browser release
↓
Download the official archive
↓
Download the OpenPGP signature
↓
Verify the archive
↓
Extract Tor Browser
↓
Launch the browser
The actual Tor Browser installation is normally placed somewhere under:
~/.local/share/torbrowser/
A typical structure looks like:
~/.local/share/torbrowser/
└── tbb/
└── x86_64/
└── tor-browser/
This distinction matters because pacman manages the launcher package, while the launcher manages the Tor Browser bundle in the user’s data directory.
torbrowser-launcher Is Not Tor Browser
The package installed through Arch Linux is best understood as:
Downloader
+
Signature verifier
+
Installer
+
Updater
+
Launcher
The actual browser is downloaded separately.
This explains why a command such as:
pacman -Ql torbrowser-launcher
shows launcher-related files, while the Tor Browser executable itself lives in the user data directory.
The browser engine is located inside the downloaded bundle, for example:
.../tor-browser/Browser/firefox.real
The Tor client bundled with Tor Browser is typically located under:
.../tor-browser/Browser/TorBrowser/Tor/tor
Those files are not conventional Arch package payloads installed directly by pacman.
The Standalone tor Package Is Different
Arch Linux also provides a package called:
sudo pacman -S tor
That package installs the standalone Tor daemon.
It is useful for purposes such as:
Tor relays
Bridges
Onion services
System SOCKS proxies
Application-level Tor routing
It is not required merely to use Tor Browser.
Tor Browser already carries the Tor client required for its own network connection.
The distinction is therefore:
torbrowser-launcher
↓
Tor Browser bundle
↓
Bundled Tor client
versus:
Arch package: tor
↓
Standalone Tor daemon
Why Tor Browser Does Not Behave Like Brave or Chromium
Chromium-based browsers generally use a very flexible application-data model.
For example:
brave --user-data-dir=/some/path
This allows one installed browser executable to use many independent data directories:
/usr/bin/brave
│
├── Profile environment A
├── Profile environment B
└── Profile environment C
The browser program and browser data are clearly separated.
Tor Browser follows a different model.
Its Linux distribution is closer to a self-contained application bundle:
tor-browser/
├── start-tor-browser.desktop
└── Browser/
├── firefox.real
├── browser/
└── TorBrowser/
└── Data/
├── Browser/
│ └── profile.default/
└── Tor/
That bundle contains not only a Firefox-derived browser, but also:
Tor client
Tor configuration
Browser profile
Privacy defaults
Anti-fingerprinting configuration
Browser resources
Security-related components
In other words, Tor Browser is designed more like:
Browser environment
+
Network environment
+
Privacy environment
rather than simply:
Browser executable
+
Arbitrary profile path
Why Tor Browser Uses a Bundle-Oriented Design
Tor Browser is not intended to be equivalent to:
Firefox
+
SOCKS proxy
Its security model depends on controlling multiple layers simultaneously.
A website can potentially observe information such as:
Screen dimensions
Window dimensions
Language
Timezone
Fonts
Graphics capabilities
Browser APIs
WebGL behavior
Operating-system characteristics
Browser preferences
Extensions
Even when the user’s IP address is hidden, an unusual combination of these properties may contribute to browser fingerprinting.
Tor Browser therefore attempts to make users resemble larger groups of other Tor Browser users.
The goal is not simply to hide the IP address.
The goal is also to reduce uniqueness.
Browser Fingerprinting and Network Anonymity Are Different Problems
Tor routing protects the network path:
Client
↓
Entry relay
↓
Middle relay
↓
Exit relay
↓
Destination
The destination normally sees the Tor exit relay rather than the client’s original public IP address.
However, consider a browser with:
Rare fonts
+
Unusual extensions
+
Unique preferences
+
Distinctive window size
+
Rare graphics characteristics
That browser could potentially remain recognizable across multiple sessions even if its exit IP changes.
This is why Tor Browser treats browser configuration as part of its anonymity system.
Simply configuring an ordinary browser to use a Tor SOCKS proxy does not reproduce the entire Tor Browser security model.
Window Size and Letterboxing
Window dimensions can contribute to browser fingerprinting.
Tor Browser therefore standardizes content dimensions and uses a mechanism commonly known as letterboxing.
Instead of exposing arbitrary content dimensions directly, Tor Browser attempts to place users into standardized size groups.
This can produce visible margins around webpage content when a window is resized or maximized.
That behavior is deliberate.
A conventional browser may prioritize:
Restore exactly the previous window dimensions
Tor Browser may prioritize:
Reduce fingerprint uniqueness
Those goals are not always identical.
This also explains why Tor Browser may reopen using a standardized window size instead of always reproducing the previous desktop geometry exactly.
The Tor Browser Profile Is Part of the Environment
The Tor Browser profile typically exists inside the browser bundle:
Browser/TorBrowser/Data/Browser/profile.default/
Tor runtime data exists nearby:
Browser/TorBrowser/Data/Tor/
This creates a structure such as:
Tor Browser bundle
│
├── Browser executable
├── Browser resources
├── Tor binary
├── Tor configuration
├── Tor runtime data
└── Browser profile
This is fundamentally different from the Chromium model:
System browser executable
↓
arbitrary --user-data-dir
Firefox internally supports profile mechanisms, but Tor Browser does not emphasize arbitrary profile switching as a primary operating model.
Its tested security assumptions are built around a known Tor Browser environment.
What Happens When the XDG Data Directory Is Changed
Linux applications commonly use XDG environment variables such as:
XDG_CONFIG_HOME
XDG_CACHE_HOME
XDG_DATA_HOME
An alternate Tor Browser environment can therefore be created by launching torbrowser-launcher with different XDG directories.
For example:
#!/bin/bash
BASE_DIR="$(cd -- "$(dirname -- "${BASH_SOURCE[0]}")" && pwd)"
export XDG_CONFIG_HOME="$BASE_DIR/config"
export XDG_CACHE_HOME="$BASE_DIR/cache"
export XDG_DATA_HOME="$BASE_DIR/data"
mkdir -p \
"$XDG_CONFIG_HOME" \
"$XDG_CACHE_HOME" \
"$XDG_DATA_HOME"
exec /usr/bin/torbrowser-launcher "$@"
The script can simply be named:
launch.sh
or:
start.sh
There is no technical reason for filenames or directories to describe the intended browsing purpose.
A neutral directory layout might be:
~/Applications/TorBrowser-A/
├── launch.sh
├── config/
├── cache/
└── data/
This naming convention has an additional privacy benefit: filesystem names do not reveal unnecessary contextual information.
Why Changing XDG_DATA_HOME Downloads Another Browser
Changing:
XDG_DATA_HOME
does not tell Tor Browser:
Create another Firefox profile.
It tells torbrowser-launcher:
Use a different application-data environment.
The launcher then looks for Tor Browser under the new data directory.
If no installation exists there, it concludes:
Tor Browser has not yet been installed in this environment.
The expected result is therefore:
Downloading Tor Browser for the first time.
After installation, a layout may resemble:
TorBrowser-A/
├── launch.sh
├── config/
├── cache/
└── data/
└── torbrowser/
├── gnupg_homedir/
└── tbb/
└── x86_64/
└── tor-browser/
This is a second complete Tor Browser environment.
It is not merely a second profile.
Chromium Profiles Versus Tor Browser Environments
The architectural difference can be summarized clearly.
Chromium-style model
One executable
│
├── Data directory A
├── Data directory B
└── Data directory C
This is lightweight and convenient.
Tor Browser-style isolation
Environment A
├── Browser
├── Tor
├── Profile
└── Configuration
Environment B
├── Browser
├── Tor
├── Profile
└── Configuration
This consumes more disk space.
However, the security boundary is simpler to understand.
Each environment can be treated as one independent unit.
Why a GnuPG Directory Appears
An isolated launcher environment may contain:
gnupg_homedir/
Processes such as:
gpg-agent
scdaemon
may also appear.
These are related to cryptographic verification.
Tor Browser releases are distributed together with OpenPGP signatures.
The launcher therefore performs something conceptually similar to:
Download browser archive
↓
Download signature
↓
Verify publisher signature
↓
Extract verified archive
↓
Run browser
The GnuPG environment is therefore part of the software-supply-chain verification process.
It is not browser-history data.
Why the Directory Contains Many Files
An isolated Tor Browser environment can contain many files immediately after initialization.
That is expected.
The directory contains far more than browser history.
It may contain:
Firefox-derived engine
Tor executable
Browser resources
Localization files
Profile defaults
Launcher state
GnuPG verification data
Tor configuration
Security components
The actual profile may contain files such as:
places.sqlite
favicons.sqlite
permissions.sqlite
prefs.js
bookmarkbackups/
storage/
SQLite databases may also temporarily create:
*.sqlite-wal
*.sqlite-shm
Tor itself maintains runtime information under its own data directory.
Therefore:
Large directory
does not imply:
Large browsing-history database
Much of the storage is simply the application bundle.
Persistent Data and Ephemeral Data
Tor Browser deliberately minimizes persistent browsing state.
A useful conceptual distinction is:
Automatically generated browsing state
↓
Temporary
Explicitly selected information
↓
Persistent
Bookmarks are a good example.
A session can disappear while deliberately saved bookmarks remain.
This implements a useful data-minimization principle:
Persistent storage should favor intentionally retained information rather than automatically preserving every browsing event.
That reduces the amount of historical behavior available from local browser data.
Data Minimization as a Security Mechanism
Privacy is not only about network traffic.
It is also about stored information.
Suppose one browser profile retains:
Years of history
Cookies
Site databases
Search records
Sessions
Download records
while another retains only:
Configuration
Bookmarks
Minimal persistent state
If both directories are later copied, inspected, or exposed, the second environment reveals much less historical activity.
This illustrates a general security principle:
Data that was never retained
cannot later leak from local storage.
Network anonymity and local data minimization therefore solve different problems.
Multiple Tor Browser Instances and Port Conflicts
Each Tor Browser instance normally launches its own Tor process.
Typical local interfaces include:
127.0.0.1:9150
127.0.0.1:9151
If two independent Tor Browser environments are launched simultaneously, both may attempt to use the same local ports.
The result can be:
Tor exited during startup
This may look like a browser failure, but the cause can simply be:
Instance A
↓
already owns Tor ports
Instance B
↓
tries to bind the same ports
↓
fails
Useful diagnostics include:
pgrep -af 'TorBrowser/Tor/tor|firefox\.real'
and:
ss -lntp | grep -E ':(9150|9151)\b'
If simultaneous execution is unnecessary, the simplest solution is to allow one Tor Browser environment to exit completely before launching another.
Why Heavy Customization Can Reduce Privacy
Tor Browser has a counterintuitive property:
More customization is not always more secure.
A conventional browser may be heavily personalized:
Custom extensions
Custom fonts
Modified preferences
Special window behavior
Unusual APIs
In an anonymity-oriented browser, every unusual property can potentially contribute to uniqueness.
Tor Browser therefore benefits from standardization.
The safer general principle is:
Stay close to Tor Browser defaults
rather than:
Modify every possible preference
A highly customized Tor Browser may become easier to distinguish from the larger Tor Browser population.
Neutral Naming Is Also Good Operational Practice
Directory and script names can reveal context unnecessarily.
For example, names describing:
Personal interests
Security intentions
Browsing categories
Identity roles
Specific use cases
provide information that the software itself does not require.
Neutral naming is preferable.
Good examples include:
TorBrowser-A/
TorBrowser-B/
TB-01/
BrowserEnv/
BrowserSet/
and scripts such as:
launch.sh
start.sh
run.sh
The filesystem should reveal only what is operationally necessary.
This principle applies beyond Tor Browser.
Neutral names are useful for:
Backup sets
Virtual machines
Browser profiles
Container environments
SSH configurations
Test directories
Automation scripts
Operational clarity does not require descriptive personal context.
Tor Browser Is a Security Environment, Not Just a Browser
The most useful way to understand Tor Browser is:
Network anonymity
+
Browser anti-fingerprinting
+
Controlled defaults
+
Minimal persistence
+
Cryptographic verification
+
Environment isolation
This explains many of its architectural choices.
It distributes a complete browser bundle because the browser itself is part of the security model.
It carries its own Tor client because Tor configuration is part of the expected environment.
It standardizes browser behavior because fingerprint uniqueness matters.
It minimizes persistent state because local history can also become a privacy risk.
It verifies downloads because software-distribution integrity is essential to the entire security chain.
A Clean Arch Linux Layout
A neutral Linux organization can look like:
System
│
├── pacman
│ └── torbrowser-launcher
│
├── Primary browser
│ └── Normal persistent profile
│
└── Tor Browser environment
├── launch.sh
├── config/
├── cache/
└── data/
├── Launcher state
├── GnuPG verification state
└── Tor Browser bundle
├── Browser
├── Tor
├── Profile
└── Runtime data
If another isolated Tor Browser environment is needed, a separate XDG root can be created:
TorBrowser-A/
TorBrowser-B/
Each environment remains understandable without embedding personal meaning in filesystem names.
Final Perspective
Tor Browser initially feels unusual to users accustomed to Chromium’s flexible --user-data-dir model.
The difference reflects different priorities.
Chromium is primarily a general-purpose browser platform with flexible profile management.
Tor Browser is a standardized anonymity environment.
Its architecture asks a different question.
Not:
How easily can arbitrary browser profiles be created?
But:
How can the browser, network stack, stored state, and observable characteristics remain controlled enough that individual users are harder to distinguish?
Once that principle is understood, many behaviors become logical.
A new XDG environment downloads another full Tor Browser because the launcher considers it a separate installation environment.
The profile lives inside the browser bundle because browser state is part of the security model.
Window behavior is standardized because dimensions contribute to fingerprinting.
Persistent state is minimized because unnecessary historical data creates unnecessary exposure.
And additional disk usage can be an acceptable tradeoff when it produces clear separation between complete browser environments.
Tor Browser is therefore best understood not merely as a modified Firefox build, but as a deliberately constrained system in which network routing, browser standardization, local-data behavior, cryptographic verification, and isolation are all components of the same security philosophy.