A VPN hides your IP, not you.

#What a VPN actually does

A VPN builds an encrypted tunnel from your device to a server the provider runs. Everything inside that tunnel is unreadable to anyone on the path between you and the server: the coffee-shop Wi-Fi, the hotel network, your internet provider. On the far side, your traffic leaves the provider's server and continues to its destination, so the website you reach sees the connection arriving from the server's IP address rather than the one your ISP assigned you.

Those are two genuine, valuable properties: confidentiality on the local hop, and substitution of the source IP at the destination. Neither is anonymity. What has really happened is a relocation of trust. Your ISP used to sit at the point where your traffic became visible and knew every site you contacted. Now the VPN provider sits in that seat instead. You have not removed the observer; you have chosen a different one and asked it to keep a secret.

#The provider becomes the one who knows

The VPN operator occupies the exact chokepoint your ISP used to: it sees your real IP on one side and every destination you reach on the other. Whether that mapping is written down is a policy and engineering decision, not a property of the encryption. The protocol does not stop the provider from logging; only the provider's own choices do.

And those choices sit inside a legal system. Providers run servers in jurisdictions with laws, and a subpoena, court order, or data-retention statute can compel them to hand over records or to begin capturing a named target in real time. A "no-logs" promise is a marketing claim. It can be supported by an independent audit, but an audit only describes the past, and it is disproved the moment a single court disclosure shows records existed. Several providers have had their no-logs claims tested exactly this way when law enforcement seized hardware or served orders.

#Traffic correlation: the shape survives

Encryption hides the content of your traffic. It does not hide that the traffic exists, nor its timing, its size, or its direction. An observer who can watch data entering the tunnel near you and watch it leaving near the provider's exit can line the two streams up by their timing and volume patterns and confirm they are the same flow, without ever decrypting a byte. This is end-to-end correlation, also called a confirmation attack.

This is the classic, well-understood limit of every low-latency anonymity system, VPNs and Tor alike. Low latency is precisely what makes the patterns survive: to feel responsive, the system cannot delay or heavily reshape your packets, so the timing signature passes through the tunnel intact. Steven Murdoch and George Danezis showed as early as 2005 that even a partial view of the network can be enough to link streams this way, and the Tor Project is explicit that this class of adversary is the one such systems do not defeat.

Who can mount it? A global passive observer in theory, and in practice any sufficiently well-placed one: a large ISP or backbone carrier, a national intelligence service, or an adversary who sees both the network near you and the provider's egress. A single commercial VPN is more exposed here than a multi-hop design, because one party, the provider, already sits at both ends of the correlation.

#Your browser is a fingerprint

Changing your IP does nothing about the rest of what your browser tells every site it touches. Fingerprinting assembles a stable identifier out of attributes the browser volunteers or can be coaxed into revealing, and none of them ride in the IP header:

• Device and rendering. User-Agent string, language headers, screen resolution and color depth, time zone, and installed fonts. Canvas and WebGL fingerprinting go further: the site draws text and graphics off-screen and hashes the resulting pixels, and tiny differences in GPU, drivers, and font rasterization make that hash device-specific.
• TLS fingerprinting (JA3). Before any HTTP is exchanged, the TLS ClientHello lists the exact cipher suites, extensions, and elliptic curves your client offers, in a client-specific order. Hashing those fields yields a JA3 value that identifies the client software and version regardless of the IP it came from.
• WebRTC. To set up peer connections, the browser can gather local candidate addresses through STUN, which has historically exposed the device's private LAN address and, in some configurations, the real public IP, straight past the tunnel.
• DNS leaks. If the operating system or app sends its name lookups to the ISP's resolver instead of through the tunnel, that resolver, and therefore the ISP, sees every domain you visit even though the traffic itself is encrypted.

EFF's Cover Your Tracks project demonstrates how few of these attributes are needed before a browser is unique among all the others it has measured. The IP is only one column in that table, and it is the one column a VPN changes.

# with the VPN "connected", these still identify the client:

# 1) WebRTC gathers ICE candidates via STUN and exposes local addresses
candidate:842163049 1 udp 1686052607 192.168.1.24 54291 typ host   # private LAN IP
candidate:842163049 1 udp 1686052607 203.0.113.9  54291 typ srflx  # real public IP (leak)

# 2) a DNS query escaping the tunnel to the ISP resolver reveals the domain
;; QUESTION SECTION:
;login.example.com.        IN  A            # ISP sees the destination

# 3) the TLS ClientHello fingerprint (JA3) identifies the client, IP-independent
ja3      = 771,4865-4866-4867-49195-49199,0-23-65281-10-11,29-23-24,0
ja3_hash = 579ccef312d18482fc42e2b822c9f5ce   # stable across IP changes

#One login ends the game

The instant you authenticate to any account tied to your identity, an email inbox, a social profile, a bank, the IP stops mattering. The service now knows exactly who is on the other end of the tunnel, and every action in that session is attributed to you by name. No amount of address substitution survives you typing in your own username.

The linkage outlives the session, too. Cookies, localStorage, and other persistent identifiers do not care about your IP. Log in once without the VPN, then reconnect through it, and the same cookie stitches the two visits together. Reuse the same account, handle, or browser profile across a "clean" identity and your real one, and you have collapsed them into a single person. This is why one login can deanonymize an entire session, and often retroactively links the sessions that came before it.

#Behavior does not tunnel

Serious attribution rarely depends on one smoking-gun identifier. It accretes from patterns that a VPN never touches, because they are carried in your behavior rather than your packets:

• Timing. When an account is active maps to a time zone and a daily rhythm of sleep and work. A few weeks of activity narrows a person to a region and a plausible schedule.
• Language and stylometry. Word choice, idiom, punctuation habits, recurring misspellings, and even code style are measurable. Stylometric analysis can link the same author across supposedly separate accounts, and it does not care which IP posted the text.
• Locale artifacts. Keyboard layout, date and number formatting, currency, spelling conventions such as color versus colour, and metadata embedded in shared files, time-zone offsets and language tags, all quietly leak origin.

None of this is concealed by a VPN, for the simple reason that none of it lives in the IP header the VPN rewrites.

#If the endpoint is owned, the tunnel is moot

Everything above assumes the adversary is somewhere on the network, outside your machine. If instead they are inside it, the VPN is beside the point. Malware, a malicious browser extension, or a compromised operating system sees your traffic before it ever enters the tunnel and after it returns, in plaintext, alongside your keystrokes, your files, and your credentials.

A tunnel protects data in transit between two computers. It says nothing about whether either computer can be trusted. A phished password, a booby-trapped document, or a supply-chain implant defeats it completely, and does so without touching the network path at all. This is why offensive operators, when a VPN stands in the way, often stop attacking the network and start attacking the endpoint.

#How investigators actually attribute

Real attribution is composition, not a single lookup. A capable investigator assumes from the outset that the source IP will resolve to a VPN, treats it as one weak signal, and builds the picture from everything the tunnel does not cover. The table below is the mental model: for each identifying signal, where it is observed, and whether the VPN helps at all.

The lesson runs both ways. For an investigator, do not over-weight the source IP; a VPN'd session is still dense with attributable signal. For a defender building detections, the same holds: correlating fingerprint, session identity, timing, and behavior will out-perform any rule that trusts the address a request arrives from.

#What a VPN is genuinely good for

Precision matters, so it is worth bounding the claim honestly rather than dismissing the tool:

• It is good for confidentiality on hostile local networks. On public Wi-Fi, it stops the network operator and anyone nearby from reading or tampering with your traffic.
• It is good for hiding destination metadata from your ISP and for not handing a website your ISP-assigned address, which is a reasonable privacy default and useful against IP-based geoblocks.
• It is not anonymity. It relocates trust to the provider and leaves your fingerprint, your session identity, your behavior, and your endpoint fully exposed.