Sheet TG-07-N8 / KIT
Kit Card on the Tor Guide Desk
Provenance first. No plot-branded browsers.
Software is the one piece of field kit that can alter every observation made afterward. For that reason, this tor guide starts with provenance rather than settings. Tor Browser should come from the Tor Project's own distribution and be checked using the signatures and instructions the project currently publishes. A destination-themed download has no place in that chain.
Branded clients appeal to recognition: a market logo, a promise of easier access, or a bundle described as preconfigured. Those features create new parties to trust and new opportunities for modification. Convenience is a poor reason to replace an upstream package whose publisher and verification practice are already known.
The satchel is deliberately sparse. It contains no wallet, deposit tool, marketplace extension, automatic mirror finder, or account assistant. Those additions would turn a client-provenance note into a funnel. The purpose here is to reduce untrusted software, not to prepare a shopping session.
I. What this tor field guide will name as client source
Use the Tor Project's official documentation as the living source for downloads and signature verification. Specific interface steps can change, so duplicating a long sequence of screenshots on a static field card would age badly and might conflict with later project guidance.
Verification is meaningful when the signing key and procedure are obtained through a trustworthy, independent path. A download page that supplies the binary, an unfamiliar key, and a green success message controls the whole story. Consult the project's current instructions rather than accepting a destination site's self-contained ceremony.
Third-party mirrors may serve legitimate resilience purposes, but an arbitrary mirror discovered through a market advertisement is not equivalent to a project-published source. This page does not maintain a mirror list because stale software links are high-risk editorial debt.
II. Onion itinerary that starts with kit, not with a string
Client provenance comes before copying any onion name. If the software environment is untrusted, a perfect visual comparison on screen cannot show what was actually requested, copied, or displayed. Later care does not repair a compromised first instrument.
Pages that reveal addresses only after an executable download, extension installation, or notification permission should be treated as hostile. Withholding a string behind software is not an authentication method. It is leverage over a reader who arrived expecting quick access.
The packing and border sheets provide adjacent context: one inventories general caution, while the other explains why ordinary browsers reject onion names. Neither page distributes binaries or converts an expected error into a pitch for special software.
III. Station notes on special browsers and VPN-only funnels
Market-branded browsers, accelerators, and one-click helpers deserve refusal even when their interfaces closely resemble Tor Browser. Logos and themes are copyable, and a package can alter proxy settings, certificates, update channels, or displayed addresses without obvious symptoms.
VPN-only funnels present another category error. VPN services and Tor have distinct trust models; an affiliate's claim that its paid tunnel is the mandatory route should not replace current guidance from the Tor Project. This card neither prescribes a VPN nor sells one.
In section III, the tor guide defines successful packing as the ability to reject an unknown client without feeling that a destination has been lost. No market visit is important enough to justify replacing signed upstream software with a branded shortcut.
Automatic updates deserve the same provenance discipline as the first download. An unfamiliar bundle may replace the project's update channel with its own. Staying with the upstream release process avoids turning every future update into another market-controlled decision.
IV. Note questions on this field card
Where should Tor Browser come from?
From the Tor Project's own distribution, following the project's current signature-verification guidance. Avoid binaries and keys supplied only by a market, affiliate, advertisement, or unknown mirror.
Why refuse a market-branded browser?
Its publisher and modifications are additional unknowns, while familiar branding is easy to copy. A themed package can interfere with addresses, updates, traffic, or displayed content.
Does this card require a VPN?
No. It rejects VPN-only sales funnels and directs readers to current Tor Project documentation for client guidance. It does not prescribe, review, or sell access services.
Close of sheet
The best kit leaves little to admire: an upstream package, a documented signature check, and the patience to stop when either is uncertain. Extra branding increases persuasion without increasing provenance.
Keep the satchel plain. The tor guide prefers software signed and explained by the Tor Project, and refuses clients or paid funnels designed around a market name.