Tor Bridge Logging: Minimize Data Retention for Privacy

Default Tor logging (notice level) records: bridge start and stop times, circuit establishment notices (without user-identifying information), bandwidth statistics, configuration warnings and errors, and heartbeat statistics (every hour). Tor does NOT log: user IP addresses of clients connecting through the bridge (by design), destination addresses users visit, user activity or timing of individual circuits, or content of any communications. The obfs4proxy component (which handles the obfuscation layer) may log connection attempts at its own log level, including the IP address of connecting clients. Review obfs4proxy logging configuration separately from Tor's torrc logging.

Reduce Tor's logging to only critical information: Log notice file /var/log/tor/notices.log (log only notices and above, not debug or info messages). Alternatively: Log warn file /var/log/tor/warnings.log (only warnings and errors, minimizing operational data). Avoid: Log info or Log debug in production - these create extremely verbose logs with detailed circuit information (though still no user IPs). For maximum privacy, logging to /dev/null discards all logs: Log notice /dev/null. Weigh operational benefit (logs help diagnose problems) against privacy benefit (no logs = no data to produce). A middle ground: Log notice with 7-day rotation covers operational diagnostics while limiting retention.

obfs4proxy has its own logging system. By default it logs at notice level to stderr/syslog. The ExtORPort or ServerTransportPlugin configuration does not directly control obfs4proxy's verbosity. To reduce obfs4proxy logging: check the ServerTransportPlugin configuration - obfs4proxy respects -logLevel flag passed by Tor in the plugin arguments. Configure in torrc: ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy -logLevel ERROR. This reduces obfs4proxy to only logging errors, eliminating notice-level connection logs that may include connecting client IPs. Snowflake proxy has similar logging level configuration.

Configure logrotate to automatically delete old logs. Create /etc/logrotate.d/tor-bridge: /var/log/tor/*.log { daily rotate 3 compress delaycompress missingok notifempty postrotate systemctl reload tor endscript }. This keeps only 3 days of logs maximum, compressed after first day. For even shorter retention: rotate hourly with rotate 1 (only current + 1 compressed hour). Consider tmpfs for log storage: mount a tmpfs (RAM disk) at /var/log/tor - logs exist only in RAM and are lost on server reboot. This provides the strongest log minimization at the cost of losing logs in unexpected shutdown scenarios. Configure tmpfs in /etc/fstab: tmpfs /var/log/tor tmpfs defaults,size=100m,mode=0750 0 0.

The jurisdiction of your bridge server affects what logs you may be legally required to retain and produce. Many EU countries have data retention directives requiring ISPs and server operators to retain certain traffic metadata, though enforcement against small operators is rare. Switzerland has strong privacy protections and no mandatory data retention for non-ISPs. Iceland has favorable privacy laws with no mandatory retention for server operators. The US has no mandatory retention law for non-telecommunications providers. Regardless of jurisdiction: if you have no logs, you can produce none in response to legal demands. A written no-logging policy stating you do not retain connection logs, reviewed by local counsel, provides documentation of your policy. Bridge operators running in EU jurisdictions should understand their country's GDPR data minimization obligations.