Privacy
Reduces unnecessary collection and exposure. It does not automatically hide identity.
MATRIX REPROGRAMMED
This page is part of the wider reporting system. Start with the summary, then open the evidence route or research tools for deeper source work.
A complete protection map for choosing the right operating system, browser, messenger, email workflow, password system, encryption, metadata cleaner, breach check, defensive monitor and public-record research tool.
Core boundary: Privacy tools reduce specific risks; they do not make a person invisible, invulnerable or immune from identification. Anonymity is a process built from threat modelling, compartmentation, endpoint security and disciplined behaviour. Use network, scanning and OSINT tools only on systems you own, administer, have explicit permission to test, or for lawful public-record research.
Reduces unnecessary collection and exposure. It does not automatically hide identity.
Requires separation between activity and identity, not merely a different browser or IP address.
Protects content and stored data. It does not hide every sender, recipient, time, device or access pattern.
Separates a user IP from destinations when used correctly. Personal logins and endpoint compromise can still identify the user.
Moves network trust to another provider. No free VPN is recommended as an anonymity solution.
Uses lawful public records and verification. It does not authorise account access, harassment, impersonation or intrusive testing.
A website that creates a private key can copy it before giving it to you. Generate PGP keys locally with GnuPG or Kleopatra, create a revocation certificate, protect the private key with a strong passphrase, keep an offline backup and verify fingerprints through a second trusted channel. For most conversations, use a modern end-to-end encrypted messenger instead.
Choose the closest threat model. The page will highlight the components that belong together. Do not install every tool or combine anonymity systems without understanding the result.
No system is selected.
Threat model: Account takeover, phishing, routine tracking, lost devices and common malware.
Threat model: Cross-site tracking, identity contamination, malicious documents, metadata leakage and accidental contact with a subject.
Threat model: Targeted surveillance, hostile networks, device seizure, censorship or a serious need to separate research identity from everyday identity.
Threat model: Message interception, account compromise, contact discovery and unsafe file exchange.
Threat model: Malware, unwanted outbound connections, weak services, malicious domains and unpatched devices.
Threat model: Exposed services, weak TLS, vulnerable web applications, brute force, malicious traffic and incomplete logs.
The directory prioritises maintained open-source projects, nonprofit safety resources and a small number of widely used free public checks. Every entry states what it does and what it cannot establish.
Start here. These guides explain risk, identity separation, safer communication and emergency response before software choices are made.
Threat modelling and practical surveillance defence.
Why it belongs: Clear guides from a leading digital-rights organisation covering passwords, encryption, protests, phones, metadata and communications.
Limits: Guidance must be adapted to local law, device condition and the actual adversary.
Step-by-step digital security for activists and human-rights defenders.
Why it belongs: Organises protection around what a person needs to defend rather than around fashionable tools.
Limits: No checklist can replace individual risk assessment or emergency support.
Maintained privacy recommendations with technical criteria.
Why it belongs: Useful for comparing operating systems, browsers, messengers, encryption and account services.
Limits: Recommendations change; verify the current project page before migrating critical data.
Initial response when an account, website or device may be compromised.
Why it belongs: Provides calm triage paths for common digital emergencies.
Limits: It is not a substitute for forensic preservation, legal advice or a qualified incident responder.
Human support for civil society, journalists, activists and human-rights defenders under digital threat.
Why it belongs: Real incidents often need confidential, contextual help rather than another software download.
Limits: Eligibility and response scope apply; use the official secure contact route.
The operating system controls every application above it. Use an amnesic system for temporary anonymity or compartmentation for persistent work.
Portable, amnesic operating system that routes internet connections through Tor.
Why it belongs: Strong defaults reduce traces on the host computer and reduce opportunities for accidental non-Tor traffic.
Limits: Hardware, firmware, personal logins, writing style and operational mistakes can still identify a user. Persistent Storage is detectable even when encrypted.
Security by compartmentalising work into isolated virtual machines.
Why it belongs: Separates personal, work, untrusted-document and anonymous activities so one compromise has a smaller blast radius.
Limits: Requires compatible hardware, disciplined use and a significant learning curve. Qubes is not anonymous by default.
Two-part Tor gateway and workstation designed to reduce IP and DNS leaks.
Why it belongs: Separates network routing from applications and integrates particularly well with Qubes OS.
Limits: A compromised host, identity contamination or malicious documents can still defeat the intended separation.
Hardened mobile operating system with exploit mitigations and permission controls.
Why it belongs: A strong choice for reducing mobile attack surface while retaining practical smartphone use.
Limits: Hardware support is limited. It is a security-focused mobile OS, not an anonymity system by itself.
Hardened Debian-based operating system used as the security foundation beneath Whonix.
Why it belongs: Useful where system hardening and documentation are needed without forcing all traffic through Tor.
Limits: Hardening reduces risk but does not guarantee immunity from malware or targeted exploitation.
Use Tor for anonymity, hardened browsers for ordinary anti-tracking, and OnionShare for direct Tor-based transfer. Do not combine tools blindly.
Routes browsing through Tor and standardises browser fingerprinting protections.
Why it belongs: The default choice when a user needs to separate their IP address from websites and resist tracking or censorship.
Limits: Do not torrent, add extensions, open downloaded documents while online, or sign into identifying accounts. Tor cannot prevent endpoint compromise or behaviour-based identification.
Routes supported mobile application traffic through Tor.
Why it belongs: Useful for censorship resistance and Tor access on mobile devices.
Limits: Not every application handles proxies safely. Prefer Tor Browser for web anonymity and verify which apps are actually routed.
Helps users connect to Tor where direct Tor access is blocked.
Why it belongs: Uses temporary volunteer proxies to make censorship blocking more difficult.
Limits: It improves reachability, not endpoint security, identity discipline or protection from global traffic analysis.
Anti-fingerprinting browser developed with the Tor Project for ordinary non-Tor browsing.
Why it belongs: Reduces tracking and fingerprint uniqueness without requiring a Tor connection.
Limits: It does not hide an IP address unless used with a separate network service. Do not confuse it with Tor Browser.
Privacy-hardened Firefox derivative for everyday browsing.
Why it belongs: Removes telemetry and applies stronger privacy defaults while retaining normal web compatibility.
Limits: A customised everyday browser is not an anonymity browser and may develop a unique fingerprint.
Efficient content blocker for trackers, malicious advertising and unwanted scripts.
Why it belongs: Reduces exposure to tracking and malvertising with transparent filter lists.
Limits: It cannot hide an IP address or repair an already compromised device. Install only the genuine project extension.
Share files, receive files, host a temporary site or chat over Tor onion services.
Why it belongs: Avoids placing files on a conventional cloud server and can provide a direct controlled transfer route.
Limits: A recipient can still redistribute files. Protect the sharing address and understand the chosen mode before use.
Modern end-to-end encrypted messaging is generally safer and easier than PGP email. Verify contacts and secure the device holding the messages.
End-to-end encrypted messages, calls and groups with strong defaults.
Why it belongs: Widely reviewed, easy to use and designed to minimise stored communication content.
Limits: Registration normally uses a phone number, and device compromise or unsafe backups can expose messages. Usernames reduce number sharing but do not remove registration requirements.
End-to-end encrypted messaging without permanent user identifiers.
Why it belongs: Reduces reliance on phone numbers, email addresses and global account identifiers.
Limits: Smaller network, less mature operational familiarity and contact-link handling still require care.
Peer-to-peer encrypted messaging that can synchronise through Tor, Bluetooth or Wi-Fi.
Why it belongs: Designed for activists and environments where internet access may be blocked or unreliable.
Limits: Android-focused, both parties need the application, and device seizure remains a serious risk.
Open-source video meetings with self-hosting available.
Why it belongs: Useful when a group needs a browser-based meeting without a proprietary account ecosystem.
Limits: Public instances have their own operators and metadata. Confirm end-to-end encryption mode and do not assume a public room is anonymous.
Email exposes metadata and is difficult to make anonymous. Use aliases for compartmentation, modern encrypted mail where practical, and local PGP only when necessary.
Desktop and mobile email client with built-in OpenPGP support.
Why it belongs: Keeps mail management in a maintained open-source client and supports local key handling.
Limits: Email headers, correspondents and timing remain visible to providers. Encryption requires correct key verification by both parties.
Encrypted email service with a free account tier.
Why it belongs: Makes encrypted mail between service users accessible and provides additional privacy features.
Limits: Email is not anonymous by default; account recovery, destination providers, metadata and device identifiers still matter.
Encrypted email and calendar with a free account option.
Why it belongs: Provides an alternative encrypted mail ecosystem with its own open-source clients.
Limits: Messages to ordinary email services cannot gain the same metadata and content protections without a shared encrypted workflow.
Create email aliases that forward without exposing a primary address.
Why it belongs: Reduces address reuse and makes it easier to disable an alias after a breach or unwanted contact.
Limits: Forwarding services can see routing metadata. Do not use one alias across identities that must remain separate.
Disposable and compartmented email aliases.
Why it belongs: Useful for reducing spam, breach correlation and unnecessary disclosure of a main address.
Limits: Aliases protect the destination address, not message content, device identity or behavioural patterns.
Local OpenPGP encryption, signing and key management.
Why it belongs: The standard open implementation for generating and controlling PGP keys locally.
Limits: PGP is easy to misuse and does not hide email metadata. Create a revocation certificate, protect backups and verify fingerprints out of band.
Graphical OpenPGP certificate and file encryption management.
Why it belongs: Provides a safer local alternative to dangerous online PGP key-generator websites.
Limits: Users still need to understand fingerprints, trust, revocation and secure private-key storage.
OpenPGP integration for supported webmail services.
Why it belongs: Can add local browser-based PGP handling where a desktop client is not practical.
Limits: Browser-extension and webmail complexity increases the attack surface. Prefer a dedicated mail client for high-risk use.
The biggest improvement for most people is unique passwords plus phishing-resistant authentication. Keep recovery codes offline.
Synchronised password and passkey management.
Why it belongs: Makes unique credentials practical across devices and supports secure sharing and auditing features.
Limits: Cloud access concentrates value in the vault. Use a strong master passphrase, MFA and protected recovery material.
Local encrypted password database without a required hosted account.
Why it belongs: Gives the user direct control over the database and sync method.
Limits: The user is responsible for backups, safe synchronisation and avoiding database loss or conflicting copies.
Encrypted local TOTP/HOTP code manager.
Why it belongs: Supports vault encryption and export, avoiding dependence on a closed authenticator.
Limits: TOTP codes can still be phished in real time. Protect encrypted exports and recovery codes.
User-friendly two-factor code management.
Why it belongs: A practical cross-platform choice with browser integration and no paid requirement for core use.
Limits: Browser integration must be secured, and TOTP is weaker than passkeys or hardware security keys against phishing.
End-to-end encrypted authenticator with multi-device access.
Why it belongs: Useful when encrypted synchronisation and recoverability are important.
Limits: Protect the Ente account, recovery key and every enrolled device.
Encryption protects stored content only when devices are locked and keys are safe. A tested backup is part of security, not an optional extra.
Encrypted containers, partitions and system drives.
Why it belongs: Mature tool for protecting substantial local collections and removable media.
Limits: Mounted volumes are accessible to malware and anyone controlling the unlocked device. Hidden-volume use has complex limitations.
Encrypt individual files before storing them in a cloud-synchronised folder.
Why it belongs: Cloud-friendly design avoids placing plaintext file content and names in ordinary storage.
Limits: Cloud providers still see account, timing, size and synchronisation metadata. Protect recovery material.
Modern, simple file encryption for scripts and technical users.
Why it belongs: Small, auditable design with straightforward recipient and passphrase modes.
Limits: Command-line mistakes, lost keys or insecure shell history can undermine protection.
Encrypted, deduplicated backups to local or remote storage.
Why it belongs: Strong fit for automated, verifiable backups across many storage backends.
Limits: Backups are useful only when restoration is tested and credentials are stored separately.
Encrypted, compressed and deduplicated backups.
Why it belongs: Efficient for repeated versioned backups and append-only remote repositories.
Limits: Requires careful repository-key management, monitoring and restore testing.
Documents and images can reveal names, devices, locations and editing history. Untrusted files can exploit readers before their content is assessed.
Remove metadata from many common file formats.
Why it belongs: Purpose-built for metadata minimisation before publication or transfer.
Limits: Some formats cannot be perfectly cleaned without conversion. Always inspect the output and keep the original separately.
Inspect, edit and remove extensive image, document, audio and video metadata.
Why it belongs: One of the most comprehensive tools for identifying hidden metadata fields.
Limits: Removing visible metadata does not remove visual clues, file hashes, cloud logs or all proprietary data structures.
Convert potentially malicious documents into safer PDFs inside isolated containers.
Why it belongs: Reduces risk from active content, embedded scripts and document exploits before reading.
Limits: Conversion can alter formatting and cannot make a compromised host safe. Preserve originals as evidence without opening them directly.
Remove caches, temporary files and application traces.
Why it belongs: Useful for routine cleanup and reducing unnecessary local data retention.
Limits: Deletion on SSDs, snapshots, cloud sync and backups is complicated. Cleanup is not a substitute for full-disk encryption or an amnesic OS.
Erase traditional hard drives and block devices.
Why it belongs: Useful for decommissioning magnetic drives through a documented wipe process.
Limits: Repeated overwriting is not reliable for many SSDs and flash devices because of wear levelling. Use manufacturer secure erase or encryption-key destruction where appropriate.
Use these to identify exposure and suspicious material. Public scanning services are not private evidence lockers.
Test tracker blocking and browser fingerprint uniqueness.
Why it belongs: Shows why blocking cookies alone does not prevent browser fingerprinting.
Limits: A test result is a snapshot and does not prove anonymity across all sites or sessions.
Confirm whether a browser request appears to exit through Tor.
Why it belongs: Useful as a basic connection sanity check before sensitive browsing.
Limits: A positive result does not prove that every application or later request uses Tor safely.
Check whether an email address appears in known breach datasets.
Why it belongs: Provides a practical signal for password replacement and account review.
Limits: Absence does not prove safety; presence does not show who used an address or whether every listed field is accurate.
Breach notifications and exposure guidance.
Why it belongs: Accessible way to monitor known breach exposure and get remediation steps.
Limits: Coverage depends on known datasets; data-broker removal features and availability vary by region.
Check hashes, public URLs and non-sensitive files against multiple security engines.
Why it belongs: Useful for triaging common malware and reputation signals.
Limits: Uploads and submitted URLs may be shared with security partners. Never upload confidential, personal, privileged or unpublished evidence.
Render and inspect suspicious websites, requests, domains and page resources.
Why it belongs: Allows safer remote observation of a web page's network behaviour.
Limits: Public scans expose the submitted URL and result. Use private scanning only when your account and policy support it; never submit secret links.
These are defensive administration tools. Use scanners and packet tools only on systems you own, operate or have explicit written authority to assess.
Capture and analyse network protocols and traffic.
Why it belongs: Essential for diagnosing unexpected connections, insecure protocols and incident timelines.
Limits: Captures may contain credentials, personal data and third-party communications. Obtain authority and protect capture files.
Inventory hosts, ports and services on authorised networks.
Why it belongs: Helps defenders discover forgotten or exposed services before attackers do.
Limits: Scanning systems without permission can violate law, policy or service terms. Do not use it for unauthorised targeting.
Application-level outbound firewall and connection visibility.
Why it belongs: Makes unexpected application connections visible and controllable.
Limits: Blocking without understanding can break updates and create false confidence; malware with high privileges may bypass controls.
Application firewall, DNS controls and connection monitoring.
Why it belongs: Provides an accessible view of which applications connect where.
Limits: Some network features are paid; local filtering is not anonymity and cannot protect a compromised kernel.
Network-wide DNS sinkhole for ads, trackers and known unwanted domains.
Why it belongs: Protects devices that cannot run browser extensions and centralises block lists.
Limits: DNS blocking can be bypassed, may break services and does not hide traffic destinations from the network resolver or provider.
Network DNS filtering and parental/security policies.
Why it belongs: Cross-platform alternative for centralised domain blocking and encrypted upstream DNS.
Limits: Blocking rules require maintenance and do not provide anonymity or malware immunity.
Temporarily block sources producing repeated suspicious log events.
Why it belongs: Simple protection against repeated password guessing and noisy automated attacks.
Limits: It depends on correct logs and filters, does not fix weak passwords and can be evaded by distributed attacks.
Collaborative detection and response for malicious behaviour.
Why it belongs: Combines local log analysis with community threat intelligence and reusable remediation components.
Limits: Community intelligence and automated blocking need careful tuning to avoid false positives and privacy issues.
Network intrusion detection, prevention and security monitoring.
Why it belongs: High-performance inspection with rule-based alerts and protocol logging.
Limits: Requires placement, rule maintenance, storage and skilled analysis; encryption limits visibility.
Network security monitoring and rich protocol metadata.
Why it belongs: Excellent for building incident timelines and understanding normal versus unusual network behaviour.
Limits: Produces substantial sensitive logs and requires analysis expertise rather than providing automatic verdicts.
Endpoint security monitoring, file integrity, vulnerability and log analysis.
Why it belongs: Provides an integrated defensive monitoring stack without a mandatory licence fee.
Limits: Operationally heavy; alerts, storage, upgrades and access control require dedicated administration.
Query endpoint state using SQL-style tables.
Why it belongs: Powerful for inventory, threat hunting and checking persistence or configuration across endpoints.
Limits: It is a data collection engine, not a complete detection platform. Protect logs and deployment keys.
Local security auditing and hardening recommendations.
Why it belongs: Fast way to identify missing controls, weak configuration and maintenance gaps.
Limits: Recommendations require context and can create disruption if applied blindly.
Malware scanning for files, mail gateways and servers.
Why it belongs: Useful as one layer in document intake and server workflows.
Limits: Detection is not complete and real-time endpoint protection varies by platform. Never rely on a single scanner.
Identify malware and suspicious files using pattern rules.
Why it belongs: Widely used by defenders to classify known families and indicators.
Limits: Rules can miss variants or generate false positives; execution and sample handling require a safe lab.
Endpoint visibility, forensic collection and incident response.
Why it belongs: Lets authorised responders query and collect evidence across managed endpoints.
Limits: Extremely powerful administrative access; protect credentials, define scope and preserve chain of custody.
External configuration checks are safe starting points. Active vulnerability testing must be authorised and carefully scoped.
Check web security headers and defensive configuration.
Why it belongs: Clear grading and recommendations for common browser-side protections.
Limits: A strong score does not prove the application or server is free from vulnerabilities.
Assess public TLS protocol, certificate and cipher configuration.
Why it belongs: Widely understood baseline for HTTPS deployment quality.
Limits: Tests public endpoints and publishes/cache results; it does not assess application logic or private services.
Quick review of important HTTP response headers.
Why it belongs: Simple way to detect missing CSP, HSTS and related protections.
Limits: Header presence is not proof of correct policy design or application security.
Intercepting proxy and web-application security testing for authorised systems.
Why it belongs: Leading open-source defensive tool for developers and website owners.
Limits: Active scans can disrupt services and generate intrusive requests. Use only with written authorisation and a defined test window.
Vulnerability assessment for authorised networks and hosts.
Why it belongs: Comprehensive open-source scanning and vulnerability-management foundation.
Limits: Scans can be noisy and disruptive; findings require validation, patch context and permission.
Map an organisation's internet-facing assets and DNS relationships.
Why it belongs: Helps authorised defenders discover forgotten subdomains and infrastructure exposure.
Limits: Collect only lawful public data or assets in scope. Do not use results to access systems without permission.
Use public records to verify claims, not to harass, stalk, impersonate or access accounts. Keep provenance, uncertainty and corrections visible.
Curated tools for maps, images, companies, transport, archives and verification.
Why it belongs: Investigation-focused organisation and practical categorisation for public-interest research.
Limits: Third-party tools have different privacy terms and accuracy. Verify important findings with primary records.
Navigate a large directory of public-information research resources.
Why it belongs: Good discovery map when the researcher knows the data type but not the available source.
Limits: A listing is not an endorsement; many external tools collect data or have commercial limits.
Automate collection and correlation of public OSINT signals.
Why it belongs: Broad module ecosystem and graphable results for defensive exposure review.
Limits: Automation creates false positives and large amounts of personal data. Restrict targets, lawful purpose, retention and publication.
Collect public domain, email, host and service references for authorised security assessment.
Why it belongs: Useful for understanding an organisation's exposed public footprint.
Limits: Do not turn public addresses into harassment or credential attacks. Results may be stale, incorrect or belong to unrelated people.
Check whether a username appears across public websites.
Why it belongs: Can help an individual audit username reuse or researchers locate public leads.
Limits: Username matches do not prove common ownership or identity. Do not use it for stalking, harassment or account access.
View preserved historical versions of public websites.
Why it belongs: Essential for tracking removed pages, changed claims and historical context.
Limits: Coverage is incomplete and captures may omit scripts, files or restricted pages. A capture proves content availability, not truth.
Search public records, leaks and entity relationships assembled for investigative work.
Why it belongs: Strong source for cross-border company, person, document and relationship research.
Limits: Records need jurisdictional context and source verification; association is not proof of wrongdoing.
Search official company-registry-derived records across jurisdictions.
Why it belongs: Useful starting point for legal entities, officers, addresses and registry links.
Limits: Coverage and freshness differ by jurisdiction. Similar names and registered-office addresses do not prove control or misconduct.
Search sanctions, politically exposed persons and related public lists.
Why it belongs: Normalises many official watchlists and provides source links.
Limits: A match can be a false positive or historical listing. Verify identity, dates, list status and legal effect in the original authority record.
Download software only from official sources. Verify hashes and signatures when a project publishes them, especially for anonymity tools.
Small public-key tool for signing and verifying files.
Why it belongs: Simple format and implementation for project releases and evidence bundles.
Limits: Verification is meaningful only when the public key was obtained through a trusted independent route.
Sign and verify software artefacts and files with transparency-log support.
Why it belongs: Useful for reproducible publication chains and modern keyless CI signing.
Limits: Identity policy, OIDC issuer and certificate checks must be explicit; a valid signature does not prove content is safe or true.
Calculate and compare file hashes from Windows file properties.
Why it belongs: Makes checksum verification accessible before installing downloaded software.
Limits: A matching hash only proves byte equality with the published value; obtain the expected hash from a trustworthy source.
Write the public-interest question, permitted scope, retention period and publication boundary before collecting personal data.
Use a dedicated operating-system account, browser profile or virtual machine. Never mix personal logins with a research identity that must remain separate.
Prefer primary records and passive public sources. Do not probe accounts, send reset requests, test credentials or interact with a subject without authority.
Hash originals, preserve provenance, open copies through Dangerzone or an isolated environment and inspect metadata before publication.
A matching username, address, company officer or sanctions-name result is a lead. Verify identity, date, jurisdiction and source context.
Publish only what is necessary, redact vulnerable third parties, state limitations and provide a route for sourced corrections.
Do not improvise a complicated anonymity stack during an emergency. Preserve essential evidence, move to a known-safe device if possible, stop unnecessary account activity and contact a qualified digital-security responder such as the Access Now Digital Security Helpline. Immediate physical danger requires local emergency and trusted-person support as well as digital measures.
Selection policy: entries must provide meaningful free access, have a defensible public reputation, solve a distinct protection problem and link to an official project or authoritative service. Inclusion is not a guarantee, endorsement of every feature or substitute for current security advisories. Registry version 1, reviewed 2026-07-12.
Open the lawful onion directory, twelve-step Tor workflow, Tails and file-quarantine guidance, non-clickable danger watch and public enforcement lessons.
Numbers on this page are public-record leads. Crime, migration, sexual-offence, payout, death, and crisis figures must be tied to named official, court, police, parliamentary, regulator, or reputable source records before they are presented as settled.
Official statistics, court records, ministry releases, police datasets, parliamentary material, regulator data, or clearly named public reports. Nationality, foreign-born status, asylum status, immigration status, charge, suspect, conviction, and victim categories must not be mixed.
When the figure matters, follow the document link, source file, court record, official release, PDF, book, or video. The visible page should help readers reach the underlying evidence fast.