A prerequisite map for Zion Market. Read the arrows, not the list. Dependency map Onion addresses
zionmarket.biznothing works until

This is not a to-do list and not a walkthrough. It is a set of conditions and the arrows between them, so you can see what your problem is actually waiting on.

Zion Market onion addresses, printed here exactly as they were supplied

Two strings, reproduced character for character as they were handed to this site. Neither one is ranked above the other and neither carries a label, because a label would be a claim and this site is not in a position to make one. Nothing here opens them, so nothing here can tell you what happens when you do.

B1 · A path to the network

A condition that must already be true

The browser came from the Tor Project

The software that opens onion addresses has to have come from the people who make it, not from a mirror, an app store listing or a friend.

Confirm by: Check the signature on the download against the published signing key before the first launch, not after.
Not this: Not a recommendation of one browser over another. It is a statement about provenance of whichever one you use.

Provenance, not preference

The condition is about one file. The thing that opens an onion address is a program, a program is a file, and a file is something whoever handed it over was in a position to change first. This card says the copy on this machine is the copy the Tor Project published, and that you established that before first launch.

You establish it with a signature. The project publishes the build, a signature over it, and the key that signature can be tested against. Verifying asks arithmetic whether the file in front of you is the file that key signed. It does not improve because the download page looked right or was spelled correctly.

  • A build from a mirror that describes itself as an official mirror. The description is written by the mirror.
  • A listing in an application store that is not the channel the project distributes through. Listings can be published under almost any name, and a name is not a provenance.
  • A copy off somebody else's drive. What you know about the person is not what you know about the file.

The reason this card sits so far upstream is unglamorous. Almost every condition after it is checked by reading something the browser shows you, so a browser that misreports what it opened does not fail those checks. It passes them. How to read a card sets out what a condition here is asked to do.

The one thing underneath it

There is exactly one card under this one: The machine is one you actually control. What it supplies is the ability for a verification to still mean something after the moment it happens.

Installing software and replacing software are the same privilege. If somebody else holds administrative control here, a good signature check tells you the file was correct at the second you checked it and nothing about the file at the second you launched it. The check has to be yours, on a machine where nothing is entitled to swap a binary underneath you afterwards.

Past that single edge, nothing on this map holds this card up. It sits one step from the roots listed on Roots and endings, and the rest of this stage hangs off it.

Everything a substituted browser makes unanswerable

Four cards depend on this, more than any other in stage B carries, and the mechanism is the same in all four. Each is checked by reading something the browser displays, so a build that does not behave as published can satisfy the display without satisfying the condition.

Cannot holdThe reason it cannot
The client can build a circuit at allThe connection indicator is drawn by the program you are questioning. A build reporting a circuit it did not construct produces a session that looks finished and is not.
There is a route out of the network you are onThat card is confirmed by running the same client on two networks. The comparison isolates the network only if the client is a fixed quantity.
The security level was set before the first page loadedThe level is a value held inside the program and read back from it. A modified build can hold the slider position while rendering by another rule.
The browser doing this does nothing elseSeparation between contexts is enforced by the software that draws them. If that software is not the published software, the separation is an assertion, not a boundary.

The damage does not stop at the edge of this stage. You hold the address as characters, not as a click and everything after it depends on characters read off a screen the browser painted. Counting to fifty six in The string has the shape an onion address has checks the string you can see, and the count comes out correct on a substitute.

You can tell a mirror from a copy of the market rests on an address being the address it appears to be, and The account name is used nowhere else rests on a login form belonging to the place you think you reached. Both inherit this card, silently.

That is what makes this the cheapest position on the map to attack. Whoever replaces the browser defeats no individual check downstream. They collect all of them at once, and nothing about a modified build has to look modified. If this is false gives the general form of the argument.

The shape of skipping the check

Skipping the check produces no symptom, and that is the whole of it. Most conditions here announce themselves when they are false. A clock hours out of true, described in The clock is close enough to right, fails immediately and repeatably. A missing circuit errors on every address. This one produces a working browser.

In the ordinary case, where the build is genuine and you did not check, the download completes, the installer runs, the program connects, pages render, and you conclude the software is fine because it behaves. In the other case the sequence is identical.

The two are indistinguishable from the chair. They differ in a number you did not compute, and the confusion, when it arrives, lands elsewhere. Something looks wrong later and the browser is the last object anyone suspects, because it has been working all along. People re-check the address, the account and the network, not the thing that mediated all three.

A check performed once, before the first launch

Take the build and its signature file from the distribution the project runs, obtain the signing key by a path that is not the page which served the binary, and verify before the program has ever started. Then read the fingerprint of the key that signed it, not only the word the tool prints.

A pass
The tool reports a good signature, the key that made it is the key the project publishes, you compared the fingerprint yourself, and none of it happened after the first launch.
A fail
No signature was offered beside the build. Or the only route to the key was the page that served the binary. Or the signature came from a key you cannot account for.
A fail that reads as a pass
You verified one copy and installed from another. The check applies to the file you tested.

None of this involves opening an address or needs a network. It is also finishable: once a build is verified on a machine that is yours, the card holds until you replace the software.

The line this card does not cross

This is not a recommendation of one browser over another, and not a claim that a verified build is a safe build. It is a statement about origin. The idea people substitute for it is downloading from the official site, which is a fact about a name in the address bar rather than about the file that arrived.

The chain around this condition

Read downwards. Everything above this card has to hold before it can, and everything below it is waiting on it. Two levels are shown in each direction; the full graph is on the dependency map.

Connected to this one

Where you are in the map