Downloading Tor Browser in the first place
Every chain in this catalogue begins with fetching a piece of software. That single request is visible in a way the later use is not, and it is generated by an enormous ordinary population.
Your ISP · The wifi operator · The distribution point
A download is an ordinary web request to an ordinary server. It happens before Tor is running, which means none of Tor's properties apply to it. The connection goes to whatever host is serving the file, over the normal internet, from your normal connection.
That makes it the most legible moment in the whole sequence, and also the least informative. The network observer can see the destination host and the approximate size. It cannot see anything about what happens next, because nothing has happened next yet.
What the download shows
Encryption protects the contents of the transfer, but the host you connected to and the volume you moved are visible, as they are for any web request. If the host is a well known distribution point, the destination is meaningful on its own. If it is a mirror, a general purpose file host or a package repository, the destination is much less specific, and the size becomes the more suggestive part.
- The host
- Which server the file came from, whether a primary distribution point or a mirror.
- The size
- A transfer in a size range consistent with a browser package.
- The time
- When it happened, and therefore when the software first arrived on this line.
- Repetition
- Later transfers of similar size to the same host, which is what an update looks like.
Updates repeat the signal on a schedule
People think of the download as a one time event and it is not. The browser updates, and each update is another transfer from the same kind of host, of a broadly similar size. Over a long period that produces a repeating trace on the line that has nothing to do with any session and is independent of whether the software is ever actually used.
This is a genuine and underappreciated point. Somebody who installed the software once and never opened it again would still generate update traffic while the installation exists. The trace is a property of having the software, not of doing anything with it. That is a meaningful distinction whenever anybody tries to read a download as evidence of activity.
Updates matter for a second reason that has nothing to do with observation. Running old software is a security problem in its own right, and the parties who benefit from you doing so are not the ones in this section. That belongs with the rest of the software on the machine.
What the download does not show
It does not show any use. Not one session, not one site, not one address, not one page. The download precedes all of that and contains none of it. A record of the transfer is compatible with the software never having been opened.
It does not show intent or subject matter. The same package is fetched by people avoiding advertising networks, by people in countries where ordinary sites are blocked, by researchers and students, by people reading about a health condition, by people who read a news article about privacy and were curious for an afternoon. The population producing this signal is enormous and overwhelmingly unremarkable, and the signal itself contains nothing that separates one member of it from another.
It does not connect you to the addresses at the top of this page, or to any market at all. That connection would have to come from a different observer holding a different record. The download is upstream of every one of those.
And it does not tell the distribution point who you are. That host sees a request from your connection like any web server does. It does not see later Tor use, because later Tor use does not go to it.
Three observers, one act
| Observer | What it holds | What it does not hold |
|---|---|---|
| Your ISP | A transfer from a known host, at a time, of a size. | Any later use of the software. |
| The wifi operator, if not at home | The same, plus which device on their network fetched it. | Who the device belongs to, unless a portal told them. |
| The distribution point | A request from an address, like any web server receives. | Anything that happens afterwards. |
The three rows differ in position, not in depth. None of them reaches past the transfer itself, which is why opening Tor at home is filed as a separate action with a separate record, made at a different time and proving something else. The rest of this observer is set out on the network hub, and the same act seen from the other six positions is on the observers page.
What changes the answer
4 things change how much this action gives away. None of them takes it to zero, and none of them is a promise.
- Verify the package rather than hiding the fetchChecking a signature protects you against receiving something altered, which is a real risk and a different one from being observed. It has no effect on the visibility of the transfer, and this site does not walk through the procedure.
- Understand that a mirror moves the signal, it does not remove itFetching from a mirror or a repository changes the destination the observer records and makes it less specific. The transfer still happened, at a time, at a size, on your line.
- Expect updates to recurUpdate traffic will keep appearing while the software is installed. Knowing that stops you reading your own record as if it were a session log. It is not something to suppress, and old software is worse than a visible update.
- Keep the download separate from the useThe record of getting the software and the record of using it are held at different times and prove different things. Conflating them is the most common error readers make about this card.
What this card is not
This card is not a download guide and does not point anywhere. It describes what a transfer looks like from the wire and how little follows from it.