How Many Independent Dependencies Does Your Privacy Chain Have?

Count the boxes in most privacy diagrams and you get three or five hops, each with a different company logo. Count the organisations that could actually act on those boxes and the number often collapses to two. A chain separates trust only as far as its dependencies are independent, and a hop count measures none of that. That gap is the entire question worth asking.

Two maps help. One traces where packets go; the other records who operates, pays for, administers and can be compelled to act on each element. The second map is unglamorous, usually incomplete, and far more likely to change a decision.

Draw the traffic path, then draw the control path

A rented proxy in front of two tunnel services looks like three parties. Write down hosting provider, control panel account, billing identity and the address a legal request would be served on, and the three may resolve to one cloud tenant with one recovery mailbox. Nothing about the traffic path changed; the description of independence did.

Label every row as known, inferred or unknown, and note what the label rests on. A brand name establishes who sold you the service. It does not establish who owns the machine, and it certainly does not establish whether customer records sit in the same database as another service's records.

The discipline matters more than the spreadsheet. Once "unknown" is an allowed value, the diagram stops flattering itself and starts showing which missing fact would flip the conclusion.

What a hop count cannot see

Hops describe encapsulation and forwarding. They say nothing about shared administration, shared upstream transit, shared payment instruments or shared recovery channels, and those four places are where two nominally different services quietly become one.

Take a design whose first and last hop belong to different companies but both sit behind the same transit provider. From that provider's position, a good deal of metadata about both ends travels the same infrastructure. That is not proof of identification; it is a dependency a hop-count summary omits entirely.

The reverse error is just as common. Assuming separate ownership guarantees separation ignores that operators get breached, compelled or simply careless in the same ways. Independence is established item by item, not conferred by a logo.

An autonomous system is a routing boundary

An AS number identifies a domain that presents a coherent routing view to its peers. That statement is about routing policy, not about corporate ownership, staffing, jurisdiction or credential separation. Two services behind different AS numbers can share an owner, and one service spread across several AS numbers is still one operator.

Reading AS numbers off a looking glass is a reasonable first pass for the transit row of your map. It is not a measurement of the path your traffic took on a particular evening, and it should not be written up as one. Where the path is unknown, write unknown.

Four rows to fill in for every hop

Work through each endpoint with the same four questions in the same order, so that gaps stay visible instead of being averaged away by a confident summary sentence.

• Who can read the contents? Name the party that terminates the protection layer and what plaintext or keys it holds.
• Who can operate the box? Distinguish the infrastructure owner from whoever holds console access, and check whether that access is shared with another service in the chain.
• Whose records could join it to something else? Billing identity, recovery address, support account and payment instrument are the usual bridges.
• Who answers a request for data? Identify the legal entity and the jurisdiction it sits in, then ask what data that entity retains at all.

Then record where each answer came from: vendor documentation, published policy, direct observation, or an inference you made because the alternative was inconvenient. A row supported by a specific retention statement is stronger evidence than a row supported by the fact that the website looked professional.

When a shared dependency actually matters

The privacy question is never whether a shared dependency exists, but what that dependency could join. Shared management access is a different exposure from passive visibility of encrypted traffic, and account linkage differs from both. Name the observation, the privilege and the retained record before concluding anything.

The observer and correlation discussion in RFC 6973 gives a workable structure: enumerate what each entity learns, then ask what combining those learnings would yield. Two parties observing similar metadata is a reason to examine correlation. It is not a measured probability of identification, and it should not be presented as one.

Worked through, the three-party example splits into separate findings. Shared hosting with no shared console access is a supply-chain concentration. A shared recovery mailbox is an administrative bridge. Both are real; only the second lets one compromise cross two boundaries.

What you end with is not a certificate of anonymity. It is a defensible statement of where independence was verified, where it was assumed, and which single fact would change your mind. That beats another arrow on the diagram.