Tor Bridge No-Log Policy: Understanding Bridge Operator Data Retention

Tor daemon logs at the notice level by default. At this level, logs include: startup events, connection events (without source IP at default log level), circuit events, and errors. The notice level does not log individual user connections or their source IPs. At the info or debug log levels, more detail is logged including connection timing information, but not source IPs in typical configurations. SafeLogging=1 in torrc causes Tor to hash potentially sensitive identifiers before logging. Bridge operators should run with SafeLogging=1 and log only at notice level to minimize sensitive data retention.

The operating system and services running alongside Tor generate logs that may be more revealing than Tor's own logs. Firewall/iptables logs record source and destination IPs for all connections passing through network rules. SSH authentication logs record connection attempts to the server. Fail2ban logs record IPs that triggered rate limiting. Web server logs (if running on the same server) record all HTTP requests with source IPs. A privacy-preserving bridge deployment minimizes all system-level logging, does not run unnecessary services on the same server, and configures OS-level log rotation with short retention periods (1-7 days maximum).

Due to Tor's cryptographic design, bridge operators cannot log the content of user traffic (encrypted by Tor's layered encryption), the destination of user traffic (the exit relay and final destination are hidden by the circuit architecture), or the user's subsequent activities after they enter the Tor network through the bridge. The bridge sees only: source IP (the user's IP), connection timing, and approximate data volume. It cannot see where the user goes within Tor or what they do. This is fundamentally different from a VPN or standard proxy, where the provider sees traffic destinations.

Bridge operators serving high-risk communities may publish warrant canaries - periodic statements confirming they have not received law enforcement requests for user data. A warrant canary statement says 'we have not received any legal process requiring user data disclosure as of [date].' If the statement stops appearing or is retracted, it implicitly signals that legal process has been received (the operator cannot lie, but can stop publishing). Warrant canaries are particularly relevant for bridge operators in community trust relationships - journalists covering repressive regimes, activists supporting vulnerable communities. The canary should be signed with the operator's PGP key for authenticity.

Configure Tor with SafeLogging=1 and Log notice file /var/log/tor/tor.log. Set log rotation to maximum 7 days retention with no archive. Disable firewall logging for normal traffic (only log anomalies). Disable SSH connection logging if possible (or restrict logging to authentication failures only). Avoid running web servers or other services that generate IP-linked logs on the same server. Use full-disk encryption on the VPS (check provider for support). Choose a hosting jurisdiction with strong legal process requirements (Iceland, Romania) that require judicial orders for data access. Publish a clear no-log policy and warrant canary if serving communities who depend on this assurance.