Threat actors
The threat model splits adversaries by vantage point: where an adversary sits decides what it can observe. Fusing them into one "observer" hides the differences that determine which tool helps. Each actor below has a level (L1 to L3G), a vantage, what it observes, and what it costs to become.
Sees only what your application makes public, out of band from the connection itself.
Is, or has compromised, the service the application connects to: the server on the other end of the session.
On the client's access network (Wi-Fi, ISP). Knows the user's IP.
Observes both ends of the communication and all intermediate hops at once.
Adversaries at every level can also hold auxiliary information: leaked account records, data from a compromised service, or activity that a previous slip already attributed to the user.
L2 is the primary adversary for most applications
The destination is the one party you must talk to directly, and it is cheap to run or compromise. For most applications that makes it the primary adversary. No amount of in-transit mixing changes what the destination sees, because mixing reshapes traffic between hops and the destination sees only what arrives. See the two-layer model for why this is the central point. All three worked examples land here: browsing, messaging, and wallet.
Two cases displace it.
- There is no destination. L2 presupposes a clearnet exit. When both ends run Nym there is no exit gateway. The other party is a Nym client, reached end to end, and it never learns your IP address. End to end, the L2 adversary does not exist. See end to end.
- The threat is the fact of communication, not its content. Journalism, activism and legal work carry this risk. The adversary is then L3G, the global network observer, also called the global passive adversary. L3G decides your configuration, and the mixnet's timing protection addresses no other actor. Choose a defence sorts the configurations by which of these you face.
What each choice buys
The distinction changes what you select for, and the two answers barely overlap.
| Defending against L2 | Defending against L3G | |
|---|---|---|
| You are buying | Identity separation at the destination | In-transit timing protection |
| Mechanisms | Exit rotation, short-lived connections, no cross-session correlators, request-shape discipline | Mixing delays, Poisson sending, cover traffic |
| Cost | Client discipline, some convenience | Latency and bandwidth |
| Does nothing about | What a network observer infers from your traffic pattern | What the destination reads once traffic arrives |
Mixing delays buy the first case very little. Cover traffic and Poisson timing buy the second case everything and do nothing about what the destination reads. Selecting the L3G configuration because it sounds stronger, without the hygiene that L2 demands, leaves the destination-facing vectors wide open. That is the category error the two-layer model describes.
L1 is application-specific
L1 is the public or out-of-band observer. What it sees depends on your application, so the worked examples define their own L1. A wallet's L1 reads the public chain; a messaging app's L1 might read a public directory. The universal spine is L2, L3L, and L3G.