Government Surveillance-Resistant Infrastructure

A service can encrypt its database and still expose users through access logs, account recovery, billing records, DNS changes, deployment systems, and administrator accounts. The practical goal is not invisibility. It is to limit what one compromise, provider failure, or lawful demand can reveal.

Start with a data map. Record which systems receive IP addresses, account identifiers, payment details, authentication events, support messages, backups, and deployment secrets. Record who can read each item and how long it remains available. If a record has no defined security or operational purpose, do not collect it.

Keep useful logs, not every possible log

Deleting all logs can make abuse response and incident investigation impossible. Keeping everything creates a detailed history of users and operators. The right policy follows purpose.

The OWASP Logging Cheat Sheet says security events should be logged, but warns that logging too much or too little both create problems. It also says passwords, access tokens, encryption keys, sensitive personal data, and data that users cannot legally consent to collect should usually be removed, masked, hashed, or encrypted rather than recorded directly.

NIST SP 800-92 treats log management as an organisation-wide process. Define which events matter, restrict access to logs, protect their integrity, and set retention from actual security and legal requirements. A universal promise such as “no logs” says little unless it identifies each system and data type.

Split control, but keep the system operable

One cloud account should not control production, backups, DNS, email, and deployment. An attacker or provider action against that account would reach every recovery path. Separate critical control planes where the added complexity is justified. Use distinct administrator identities and phishing-resistant authentication. Keep recovery material outside the production environment and test recovery before an incident.

Separation has a cost. More providers mean more accounts, invoices, credentials, and chances for configuration errors. Document ownership and access. Remove former maintainers promptly. Keep a tested procedure for rotating keys, moving DNS, restoring clean backups, and publishing a status notice.

Use onion services for a defined threat

A Tor onion service can protect the service IP address and provide an authenticated, encrypted path between a Tor client and the service. The Tor Project's protocol overview explains that clients and services build separate circuits to a rendezvous point. The service does not expose its IP address through the onion-service protocol.

That protection has boundaries. The application can still leak identifiers. Administrators can expose themselves through account reuse, payments, support activity, deployment access, or mistakes outside Tor. A compromised host can reveal its own environment. Keep the onion service separate from public administration surfaces, patch the host, and avoid treating Tor as a substitute for application security.

IPFS distributes content, not responsibility

IPFS addresses content by its hash and lets multiple nodes host the same data. It does not guarantee that a file stays available. The IPFS documentation on persistence says cached content can be removed by garbage collection. Content must be pinned to one or more nodes to persist.

Putting a file on one commercial pinning service replaces one hosting dependency with another. Important public material needs independent pins, monitored availability, and an ordinary export that can be published elsewhere. Do not publish secrets or personal data to a content-addressed network. Removing every copy may be impossible once other nodes retain it.

Plan for lawful demands and account loss

Provider location does not erase legal exposure. A company can face demands where it operates, where its staff work, or where related entities hold records. Cross-border procedure changes by case and jurisdiction. Get qualified advice for a specific operation rather than relying on a country ranking or a provider's marketing.

Technical design still changes what can be produced. A provider cannot disclose application records it never receives. A seized server cannot reveal an offline key that was never stored there. These controls reduce exposure, but they do not prevent endpoint compromise, infiltration, software vulnerabilities, traffic analysis, or mistakes by people with access.

Test the failure, not the slogan

Run exercises against specific events: the main host disables the account, a registrar locks the domain, an administrator loses a security key, a backup credential leaks, or a server is copied. Measure what stops, what data becomes available, and how long recovery takes.

Surveillance resistance comes from narrow collection, protected administration, independent recovery, and honest limits. Tor can hide a service address. IPFS can distribute public files. Encryption can protect stored content. None of them makes the surrounding operation disappear.

Sources

• NIST: Guide to Computer Security Log Management
• OWASP: Logging Cheat Sheet
• Tor Project: How Onion Services Work
• IPFS Docs: Persistence, Permanence, and Pinning