Two addresses that look the same on the screen
Two different things can present themselves at two different addresses. One is another address run by the same people who run the service you meant to reach. The other is an address whose pages resemble that service and which is run by somebody else. This card is the condition that you know what separates them, before anything is typed into either.
Start with what does not separate them. A page can be reproduced in full. The layout, the wording, the images, the order of the menu, the phrasing of the error you get when you type a password wrongly, all of it can be copied, and copying it is not difficult. A form that accepts what you type and responds sensibly is not evidence either. If the two are indistinguishable in a browser window, the distinguishing evidence is not in the browser window, and no amount of careful looking will produce it. That observation is most of the card.
What is left is the address itself. An onion address is derived from the service key, which has two consequences. The first is that no third party stands in the middle able to point that string somewhere else. There is no separate record to alter and no intermediary to persuade, so the string and the service stay bound together. The second is that a lookalike is not a redirection of your string. It is a different service with a different key and therefore a different string, at an address of its own.
So the property the derivation gives you is continuity of key control, and it is worth being blunt about what that is not. It means the thing answering at that string is the thing holding that key. It says nothing about whether the operator is honest, whether they will still be there later, or whether the key is in the hands you assume. Identity across time is not conduct. The practical question is narrower: which strings does the operator publish, and by what route did you come to hold yours. That last part is the repeatable route condition, which is why these two cards lean on each other.
What has to be true before the distinction is even available
The string has the shape an onion address has supplies an object for the question to be about. The distinction is between two services, and a string of the wrong shape is derived from no key and stands for no service, so asking who operates it has no possible answer.
The client can build a circuit at all supplies informative outcomes. With no path through the network every address behaves identically, and identical behaviour carries no information. The point is not that you should go and try things. It is the reverse: when the path is broken, anyone reasoning from outcomes is reasoning from noise.
The security level was set before the first page loaded supplies ordering. A page from an address whose operator you have not established is exactly the case that setting governs, and it only ever governs the future. Adjusted afterwards it applies to pages that have not run yet, which is no help for the one that already did.
The identity conditions that follow
One card depends directly on this one and it opens the next stage. The account name is used nowhere else is where you first hand over something durable. A name typed into a registration form is published, in the plain sense that it now exists outside your control and cannot be recalled. Typed into a lookalike, it is published to somebody unknown, and it has been used in a second place, which is the thing that card exists to prevent. The failure is permanent in a way most failures here are not: a password can be changed and a store rebuilt, but a name that has appeared somewhere has appeared.
| Cannot hold | The reason it cannot |
|---|---|
| The account name is used nowhere else | A name given to an unidentified service now exists in a second place, and no later care undoes it |
From that node the whole of stage D inherits the problem, in an unusual form. The password outside your head, the second factor you can produce and the phrase written down can all be satisfied perfectly, and so can logging in a second time. Every one of those is defined relative to the market, so if the referent is wrong each is true about the wrong thing. Nothing reports an error, because from the software point of view nothing has gone wrong. You have built a complete chain aimed somewhere else. Roots and endings and If this is false make the same point, and this card is its sharpest instance.
Skipping it: the chain that works and points elsewhere
The skipped version is quiet. Pages render. The registration form takes what you type. A session appears to exist. There is no warning, because a copy that could not manage those things would not be worth constructing.
The first symptom arrives much later, disguised as an unrelated problem. A session that does not exist when you return. Value that went somewhere and is not visible where you expected. An order nobody has any record of. Each reads as a fault in the market, and that is where the reader takes it, which is why the confusion here lands on the wrong party. The evidence that would have settled it was never on the page.
Asking what would change your mind
The check is a question you put to yourself about a specific string, and it opens nothing. Ask what evidence would make you conclude the string is not what you think it is. Then ask whether you could actually obtain it.
A pass is naming a concrete artifact and a route to it that you already hold. A fail is any answer that reduces to the page looking correct, or to a page having appeared at all. Appearing is not evidence, because a copy appears too, and a copy that failed to appear would have no purpose. If the honest answer is that nothing would change your mind, the string is not being trusted for a reason. It is being used, and it is better to know that than to call it a check.
Not a whitelist
This card publishes no verdicts. It names no address as good and none as bad. This site prints exactly two strings, at the top of every page, without labels, without ranking and without commentary, and makes no claim about any other string in existence. That is deliberate, and it is set out in About this site and on the onion addresses page. Nor is this an argument that key derivation makes an address trustworthy. The derivation gives continuity, and treating a technical property as an endorsement is the mistake this card exists to name.