Fingerprinting beyond cookies
With third-party cookies in decline (Safari ITP, Firefox ETP, Chrome rolling slowly), trackers shifted to fingerprinting. The signal sources, roughly in order of entropy:
- Canvas fingerprinting: draw text and a few shapes, hash the rendered pixels. GPU, driver, font hinting, and antialiasing all leave traces. Reliably distinguishes most devices.
- Audio fingerprinting: process a known signal through an OfflineAudioContext, hash the output. Floating-point variations across CPUs and OS audio stacks are stable.
- Font enumeration: measure rendered widths of probe strings in different fonts; build the installed-font set.
- WebGL parameters: GPU vendor and renderer strings, supported extensions.
- TLS fingerprinting (JA3, JA4): cipher suite list and extension order in the ClientHello identifies the TLS library, not just the browser.
- Network stack: TCP options, MSS, window-scaling factor (p0f-style).
Defenses: Tor Browser normalizes most of these by quantizing canvas, blocking WebGL by default, and shipping a fixed font list. Brave randomizes per-session. Standard browsers do almost nothing.
Tor: how circuits actually work
A Tor circuit is three relays: a guard, a middle, and an exit. The client builds the circuit incrementally, performing a key-exchange with each hop using the previous hop as a relay. Each layer is encrypted under that hop's key; only the exit sees the destination, only the guard sees the client.
Guard relays are the durable trust anchor. Since Tor 0.3.0 (2017, proposal 271), clients keep a single primary guard for ~2-3 months, with a small sampled set behind it for fallback. The reason for stickiness: rotating guards every circuit gives an adversary running a fraction f of relays roughly f probability per circuit of being on path; sticky guards make it all-or-nothing.
Onion service circuits add three more hops on the server side, meeting at a rendezvous point neither client nor server picks. Result: six-hop circuit, neither end knowing the other's IP.
Traffic-analysis attacks on Tor
Tor was never intended to defeat a global passive adversary. Real attacks:
- Correlation: if you control both the guard a user picks and any exit, you can match flows by timing and size. With ~7000 relays and adversaries running ~hundreds at peak, this is a probability-of-deanonymization argument.
- Website fingerprinting: a machine-learning model on encrypted Tor traffic can identify which page on which site was loaded with >90% accuracy in closed-world setups. Open-world (any page on the internet) is harder but research keeps improving.
- Application-layer leaks: a torrent client over Tor still includes the local IP in the BitTorrent handshake. A PDF auto-fetching a remote image bypasses Tor entirely.
The 2014 Operation Onymous (Silk Road 2.0) and the de-anonymization research by CERT/CMU illustrated that bandwidth-and-relay-count attacks on Tor are within budget for nation-state and even university-research adversaries.
Pluggable transports
In censoring countries, the IP list of Tor relays is published. Solution: pluggable transports that wrap Tor traffic to look like something else.
- obfs4: makes Tor look like random bytes, defeats DPI looking for the TLS-Tor signature. Relay IP is still needed and must be private (bridges).
- meek: domain fronting. The TLS SNI says allowed-domain.com, but the HTTP host header inside routes to Tor. Burned by Google and AWS dropping domain fronting in 2018.
- Snowflake: each volunteer browser tab in a free country becomes an ephemeral WebRTC bridge for someone in a censoring country. Defeats blocklisting because the IPs are residential and short-lived.
Mixnets vs onion routing
Tor optimizes for low latency, which inherently leaks timing. Mixnets reverse the trade: deliberately batch and shuffle messages so that, in a window, you cannot tell which input maps to which output.
Loopix (2017) and its production heir Nym add cover traffic and Poisson-distributed delays. The cost: messaging-style latency, not browsing latency. The benefit: provable resistance to traffic analysis even under stronger adversaries than Tor's.
Use-case fit: Tor for web browsing where the user accepts some risk for speed; mixnets for high-value targets where the latency cost is acceptable (a journalist messaging a source, not loading Twitter).
Differential privacy
DP is the rigorous answer to "how do I publish aggregate statistics without leaking individuals?" A mechanism is (epsilon, delta)-DP if the output distribution barely changes when any one input changes. Smaller epsilon = stronger privacy.
Production deployments:
- US Census 2020: used the TopDown algorithm with hierarchical noise injection. Sparked controversy because small-population groups (rural blocks, racial minorities) suffered the most accuracy loss.
- Apple: collects telemetry (emoji frequency, autocomplete fixes) with local DP and an aggressively small per-day epsilon budget.
- Chrome RAPPOR (deprecated) and follow-on systems for crash and usage stats.
The catch: epsilon is a knob, not a guarantee. Small epsilon limits how much one query reveals, but composition across many queries adds up. Real systems carefully budget total epsilon over a user's lifetime, which means privacy-preserving analytics is itself a non-trivial engineering discipline.