Cover traffic on a VPN: which observer are you hiding from

Imagine you share a coffee-shop network with someone using a VPN, and all you can see is packet sizes and timing. Cover traffic is supposed to blur that picture. Walk the padding from the laptop to the gateway and the blur turns out to be local: it ends where the gateway ends. Everything after that point is a fresh observation problem on the same real traffic.

So the first question is never how much filler to send. It is which observer you are hiding from, and where that observer sits.

Start at the laptop

On the local link an observer sees encrypted packets leaving and arriving. Without padding, a large upload is a run of full-size packets, a call is a steady medium-size stream, and an idle client emits keepalives. Those shapes correlate with what the user is doing even when the contents are unreadable. Filler can smooth the shape, at the price of sending bytes nobody asked for.

Write down what that observer would otherwise notice: a burst at the start of a transfer, a gap when a call ends, a rhythm of idle periods. If you cannot name the feature, you cannot claim the filler hides it.

Follow the filler to the gateway

The laptop sends padding to a cooperating gateway, which discards it and forwards real traffic onward. That cooperation is the mechanism: without an endpoint that removes the filler you have added load to someone else's path rather than created cover. The Tor padding specification makes the same split explicit, with link padding between adjacent relays and circuit padding tied to protocol state.

Now consider what the gateway sees. It sees the real traffic plus the filler, which means it learns more rather than less unless it is the party you trust. Cover traffic relocates trust; it does not remove the need for it.

Then watch the second segment

Past the gateway, the onward connections to real destinations are ordinary traffic with ordinary shapes. An observer there, whether a hosting provider or the destination network, sees the same bursts the padding was meant to hide. If that observer was the one you cared about, the padding did nothing for you. This boundary is the whole point of walking the path.

Cover traffic is scoped to a segment, and extending the scope means extending the cooperation.

Direction and shape

Padding sent only outward hides the timing of what you send. It says nothing about the timing of what comes back, because replies arrive on their own schedule. Asymmetric hiding is normal and worth stating out loud: a download-heavy session still shows its shape on the inbound side.

Packet length, burst structure, start and stop times, and inter-arrival gaps all carry information. A byte counter that stays flat can coexist with a very recognisable packet-size distribution. Flat totals are not flat behaviour.

What the budget buys

Filler consumes capacity someone pays for: metered data, uplink contention, queueing delay for other users on the same connection. Following the maximum available rate is also self-defeating, because that maximum moves with the link and the filler then moves with it. A stated budget, with stated behaviour when the budget is exhausted, is the difference between a mechanism and an accident.

Evaluate the result against the observation you named at the start. A test showing reduced recognition under a defined observer is a result; a promise that more traffic means less information is not.

Deciding whether to do it at all

For most people the answer is no, and the honest reason is that a full-speed background stream is a poor substitute for software that documents what it protects. Padding is legitimate engineering, and it belongs in designs that name their observer, their cooperating endpoints, their cost and their limits. It is not a checkbox that converts a VPN into an anonymity system.

If you do implement it, write the observer model down first. Every later decision, from packet sizes to shutdown behaviour, follows from that one paragraph.