Official Onion URL: https://catharibrmbuat2is36fef24gqf3rzcmkdy6llybjyxzrqthzx7o3oyd.onion/
VPN No-Logs Policies: Separating Fact from Marketing Claims | Catharsis Market Wiki

VPN No-Logs Policies: Separating Fact from Marketing Claims

The phrase "no-logs VPN" has become one of the most overused and misleading marketing terms in the privacy industry. Nearly every commercial VPN provider claims to keep no logs of user activity, yet the reality is far more nuanced, and in several high-profile cases, providers have been caught handing over data they claimed never to have collected. Understanding what "no logs" actually means, what types of data VPN providers can and do collect, and how these claims have held up under legal scrutiny is essential knowledge for anyone who relies on a VPN as part of their privacy strategy.

This article provides a rigorous, technically grounded analysis of VPN logging practices, examines real-world court cases that have tested no-logs claims, discusses the critical differences between VPN over Tor and Tor over VPN configurations, and offers guidance on evaluating VPN providers based on verifiable evidence rather than marketing copy. For a comprehensive understanding of how to combine VPNs with other anonymity tools, see our Complete Tor Browser Guide.

What "No Logs" Actually Means (and Does Not Mean)

When a VPN provider advertises a "no-logs" or "zero-logs" policy, they are typically making a claim about one or more of the following categories of data. However, the specific definition varies enormously between providers, and the devil is always in the details of the privacy policy.

Types of VPN Logs

Connection logs (metadata): These include timestamps of when you connected and disconnected, the duration of your session, the IP address you connected from, the VPN server IP address you connected to, and the amount of data transferred. Many providers that claim "no logs" are actually only claiming they do not keep activity logs while still retaining connection metadata. Connection logs alone can be extremely revealing when combined with other data sources.

Activity logs (usage logs): These include the actual content of your internet traffic -- the websites you visit, files you download, searches you perform, and any other online activity. Keeping activity logs would be the most egregious violation of a no-logs claim, and it is also the most storage-intensive form of logging. Most reputable VPN providers genuinely do not keep activity logs, as it would be prohibitively expensive and would serve no legitimate business purpose.

Aggregate logs: Some providers maintain anonymized, aggregate statistics about bandwidth usage, server load, and general usage patterns. While these are not linked to individual users, the question of what constitutes truly anonymized data is more complex than most providers acknowledge. Re-identification attacks on supposedly anonymized datasets are well-documented in the academic literature.

Account logs: Almost every VPN provider keeps some form of account data -- email addresses, payment information, subscription status, and support ticket history. These are not typically what providers refer to when claiming "no logs," but they are relevant to your overall privacy posture. A provider that accepts cryptocurrency and does not require email verification collects meaningfully less identifying information than one that requires a credit card and verified email.

The Jurisdiction Problem

A VPN provider's legal jurisdiction significantly impacts its ability to maintain a no-logs policy. Providers based in Fourteen Eyes countries (the United States, United Kingdom, Canada, Australia, New Zealand, Denmark, France, the Netherlands, Norway, Germany, Belgium, Italy, Sweden, and Spain) are subject to intelligence-sharing agreements that may compel them to collect and share data.

However, jurisdiction is not the only factor, and it is often overstated in VPN marketing. A provider in a "privacy-friendly" jurisdiction can still be compelled to collect data through mutual legal assistance treaties (MLATs), and a provider in a Fourteen Eyes country can still resist data requests if it genuinely has no data to provide. The technical architecture matters more than the legal jurisdiction -- if the VPN's infrastructure genuinely does not log data, there is nothing to hand over regardless of jurisdiction.

The Privacy Guides VPN recommendations provide well-researched evaluations that consider jurisdiction alongside other critical factors like ownership transparency, security audits, and technical architecture.

Court Cases and Real-World Evidence

The most reliable way to evaluate a VPN's no-logs claim is to examine cases where providers have been legally compelled to produce data. These real-world tests are far more meaningful than marketing promises or even third-party audits.

PureVPN and the FBI (2017)

Perhaps the most infamous case involved PureVPN, a provider that prominently marketed a "zero logs" policy. In 2017, the FBI was investigating a cyberstalking case and served PureVPN with a court order for data related to a suspect. PureVPN complied and provided records that included the suspect's real IP address, connection timestamps, and the VPN IP addresses used. The data directly contradicted PureVPN's zero-logs marketing and led to the suspect's arrest and conviction. PureVPN subsequently updated its privacy policy to more accurately reflect its logging practices, but the damage to its credibility was permanent.

IPVanish and Homeland Security (2016)

IPVanish, another VPN provider that advertised a strict no-logs policy, was revealed to have provided connection logs to the Department of Homeland Security in a 2016 criminal investigation. The affidavit showed that IPVanish provided detailed connection records, including dates, times, source IP addresses, and VPN IP addresses associated with the suspect's account. Like PureVPN, IPVanish had explicitly marketed itself as a no-logs provider at the time.

ExpressVPN and the Turkish Investigation (2017)

In a contrasting case, Turkish authorities seized an ExpressVPN server as part of an investigation into the assassination of the Russian ambassador to Turkey. Despite physical access to the server, investigators were unable to find any useful logs or data. ExpressVPN stated that this was because their servers run on RAM-disk (volatile memory) and do not write to persistent storage, meaning all data is lost when the server is powered off or rebooted. This case is often cited as evidence that ExpressVPN's no-logs claim is technically credible.

Mullvad and the Swedish Police (2023)

In April 2023, Swedish police raided the offices of Mullvad VPN in Gothenburg as part of an international investigation. Mullvad stated that the police left without taking any data because there was nothing to take -- the company does not log user activity, does not know who uses its service (it uses account numbers rather than email addresses), and accepts cash payments through the mail. This case bolstered Mullvad's reputation as one of the most privacy-focused VPN providers available.

Evaluating VPN Providers: What to Look For

Based on the evidence from court cases and technical analysis, here are the key factors to consider when evaluating a VPN provider's privacy claims:

RAM-only servers: Providers that run their servers entirely in RAM (rather than writing to disk) are structurally incapable of retaining data across server reboots. This is a strong technical guarantee that complements any legal or policy commitments. ExpressVPN, Mullvad, and several other providers have adopted this approach.

Independent security audits: Reputable providers commission independent audits of their infrastructure and code from firms like Cure53, PricewaterhouseCoopers, or KPMG. While an audit is a snapshot in time and does not guarantee ongoing compliance, it does provide meaningful evidence that the provider's claims are not purely aspirational.

Open-source clients: VPN providers that publish the source code of their client applications enable independent verification of their behavior. You can examine the code to confirm that the client is not collecting telemetry, transmitting identifying information, or behaving in ways that contradict the provider's privacy policy. Mullvad's clients are fully open-source and available on GitHub.

Anonymous payment methods: Providers that accept cryptocurrency (particularly Monero), cash, or other pseudonymous payment methods allow you to subscribe without providing financially identifying information. This reduces the account-level data that the provider holds about you.

Warrant canary: Some providers maintain a warrant canary -- a regularly updated statement asserting that the provider has not received any secret government orders to collect data. If the canary disappears, it signals that the provider may have been served with a gag order. While the legal enforceability of warrant canaries is debated, they provide a useful signal.

VPN over Tor vs Tor over VPN

One of the most frequently debated topics in the privacy community is whether to use a VPN in combination with Tor, and if so, in what order. Both configurations have distinct advantages and disadvantages, and the optimal choice depends on your specific threat model.

Tor over VPN (Connect to VPN first, then Tor)

In this configuration, you connect to your VPN first, and then launch the Tor Browser. Your traffic flows: You -> VPN -> Tor Entry Guard -> Tor Middle Relay -> Tor Exit -> Destination.

Advantages of this approach include: your ISP cannot see that you are using Tor (they only see a VPN connection); the Tor entry guard sees the VPN's IP address rather than your real IP; and if the VPN provider keeps no logs, there is an additional layer of separation between your real identity and the Tor network. This is particularly useful in jurisdictions where Tor usage itself may attract unwanted attention.

Disadvantages include: you are now trusting the VPN provider with knowledge that you are a Tor user; if the VPN connection drops while you are using Tor, your real IP may be briefly exposed to the Tor entry guard; and the VPN provider becomes a permanent point of entry that, if compromised, could be used to correlate your sessions over time.

VPN over Tor (Connect to Tor first, then VPN through Tor)

In this configuration, you route your VPN connection through the Tor network. Your traffic flows: You -> Tor Entry Guard -> Tor Middle Relay -> Tor Exit -> VPN -> Destination.

This configuration is much more complex to set up and is generally not recommended for most users. It requires a VPN provider that accepts connections from Tor exit nodes and does not require information that would identify you. The main advantage is that the VPN provider cannot see your real IP address -- they only see the Tor exit node's IP. This can be useful for accessing services that block Tor exit nodes, as the destination sees the VPN's IP rather than a known Tor exit.

However, this configuration has significant drawbacks: it removes the anonymity protection of Tor at the final hop (the VPN provider can see your traffic), it is slow and technically complex, and if the VPN provider keeps logs, those logs could potentially be correlated with Tor exit relay logs to de-anonymize you.

The Prevailing Expert Consensus

The prevailing consensus among security researchers and the Tor Project itself is that adding a VPN to a Tor setup does not necessarily improve anonymity and can in some configurations actually reduce it. The Tor network is specifically designed to provide anonymity without requiring trust in any single entity. Adding a VPN introduces a trusted third party into the equation. The Whonix documentation on VPN tunneling provides a thorough technical analysis of these configurations and their security implications.

The WireGuard Question

WireGuard is a modern VPN protocol that has gained enormous popularity due to its simplicity, speed, and small codebase (roughly 4,000 lines compared to OpenVPN's hundreds of thousands). However, WireGuard was designed with a fundamentally different philosophy than traditional VPN protocols -- it requires a static IP address to be stored on the server for each peer, which inherently conflicts with a no-logs policy.

VPN providers that use WireGuard have implemented various workarounds to address this. Mullvad, for example, has developed a system that periodically wipes the association between user accounts and WireGuard public keys. NordVPN developed a custom system called NordLynx that adds a double NAT layer to WireGuard, ensuring that no identifiable IP address is stored on the server. The WireGuard source code is available on GitHub, allowing independent review of the protocol implementation.

It is worth noting that these workarounds add complexity and potential attack surface to what is otherwise a remarkably clean protocol. Users who prioritize the ability to verify the no-logs architecture may prefer providers that use OpenVPN, where the server can be configured to log nothing by default without requiring additional engineering.

Video Resources

The Hated One provides an excellent analysis of VPN logging claims and the trust problems inherent in the VPN industry:

For a technical deep-dive into VPN protocols and their security properties, this presentation is highly recommended:

DNS Leak Prevention

One of the most common ways that VPNs fail to protect privacy is through DNS leaks. When you type a domain name into your browser, your computer needs to resolve that name to an IP address through a DNS query. If your VPN is not properly configured, these DNS queries may bypass the VPN tunnel and be sent directly to your ISP's DNS servers, revealing every website you visit even though your actual traffic is encrypted through the VPN.

A robust VPN client should force all DNS queries through the VPN tunnel and use the provider's own DNS servers (or other privacy-respecting DNS servers). You can test for DNS leaks using tools like dnsleaktest.com or ipleak.net. On Linux, you can also verify DNS routing from the command line:

# Check current DNS resolver
resolvectl status

# Verify DNS queries go through VPN interface
sudo tcpdump -i any port 53 -n

# Test for DNS leaks manually
nslookup example.com
dig +trace example.com

Some VPN clients also implement a kill switch, which blocks all internet traffic if the VPN connection drops unexpectedly. Without a kill switch, a momentary VPN disconnection can expose your real IP address to any services you are connected to. The EFF's guide on choosing a VPN covers these technical considerations in detail.

Beyond VPNs: When a VPN Is Not Enough

It is critical to understand the limitations of VPNs. A VPN encrypts your traffic between your device and the VPN server, and it hides your real IP address from the websites you visit. However, it does not make you anonymous. The VPN provider is a single point of failure -- if they log data (intentionally or through a compromise), your privacy is lost. If they are compelled by a court order in a jurisdiction that can reach them, your privacy may be lost.

For genuine anonymity, tools like the Tor Browser provide mathematically grounded anonymity guarantees that do not depend on trusting any single entity. For maximum protection, consider using Tails OS, which routes all system traffic through Tor and leaves no trace on the computer you use. VPNs are useful tools within a broader privacy strategy, but they should never be your only line of defense.

The Privacy Guides community maintains an actively updated comparison of VPN providers at privacyguides.org, considering factors like ownership, audit history, protocol support, and jurisdictional analysis. This is one of the most trustworthy resources available for evaluating VPN providers based on verifiable evidence rather than affiliate marketing incentives.