Privacy Policy for Tor Hidden Services: Writing What You Actually Do

A Tor hidden service that is properly configured collects significantly less data than a clearnet website. No IP addresses: clients appear as 127.0.0.1 from the Tor process - no real IP addresses in application logs. Account information: only what users voluntarily provide at registration (username, password hash, optional email if provided). Content data: posts, messages, uploads created by users. Server-side logs: Nginx access logs (timestamp, path, HTTP status code, response size) with no real IP. Application errors and events (not keyed to user identity). This is the baseline for a well-configured hidden service.

A privacy-respecting hidden service explicitly avoids: real-time logging of user activity beyond technical necessity, long-term retention of access logs (7-day maximum is generous; many operators log to /dev/null), browser fingerprint information (Tor Browser is designed to normalize fingerprints - do not try to collect them), precise timestamps correlated with user accounts (access patterns reveal behavior), and any data that would link user accounts to real-world identities. Clear statement in privacy policy: 'We do not log IP addresses, device information, or browser fingerprints. Access logs are stored for [X days/not stored] for technical operations only.'

Under various data protection frameworks (GDPR in EU, CCPA in California), users have rights over their personal data. For a hidden service operator: right to access (users can view their account data and content), right to deletion (account deletion removes user-generated content or anonymizes it), right to export (provide user's data in downloadable format). For hidden services in jurisdictions without formal data protection law (outside EU/California/similar): still articulate user rights as a statement of values rather than legal obligation. If operating from a country with no binding data protection law, be clear about that rather than falsely implying GDPR applies.

Be honest in your privacy policy about what could be produced in response to legal demands. If you log timestamps of user activity: state this and your retention period. If you require email addresses: state this and what law enforcement access would reveal. If you have no logs of user activity: state this. For a properly configured hidden service with minimal logging: 'In response to a valid legal request, we can provide: account creation timestamp, username, any voluntarily provided contact information, and user-generated content. We cannot provide: IP addresses (never collected), device information (never collected), access history (not retained beyond X days).' This is honest and demonstrates your actual data practices.

A hidden service privacy policy should include: operator's pseudonymous contact information (a .onion address or anonymous email for privacy inquiries), the jurisdiction where the hidden service operator is located (or 'operator jurisdiction is not publicly disclosed' if anonymity is maintained), and a statement about the server's hosting jurisdiction (the location where data is stored). If you are operating anonymously: 'This service is operated by [pseudonym]. The operator's jurisdiction and the server's physical location are not publicly disclosed as part of the operator's operational security.' This is honest. Do not invent a false jurisdiction or pretend to be in a jurisdiction whose laws you are not actually subject to.