Summary

  • RFC 9614 defines privacy partitioning as keeping information about “who” separate from information about “what”. The relevant unit is a context: the data, metadata and entities that share access.
  • A relay, gateway, encrypted tunnel or second proxy is not a privacy receipt. Common ownership, stable identifiers, application disclosures, aligned logs, packet timing, message size and fallback routes can reconnect the partitions.
  • A defensible deployment records the context map, operator independence, visible identifiers, retention and joinability, side-channel exposure, bypass behavior and measured linkage resistance.

The first review looks excellent. The client encrypts an HTTP request for a gateway and sends it through a relay. The relay knows which client connected, but the encapsulated request is opaque. The gateway opens the request, but the connection comes from the relay rather than the client. A privacy diagram places “who” on the left and “what” on the right. Two boxes stand between them.

The second review asks who operates the boxes. The answer is the same company. Its relay log records a request of a particular size at 09:17:04.281. Its gateway log records an encapsulated message of the corresponding size milliseconds later. Retention policy keeps both records under one analytics account. No cryptography was broken. Neither service had to violate its local protocol role. The person and action were reconstructed by joining observations that the architecture had described separately.

This is the difference between separation and unlinkability. Separation is a topology. Unlinkability is an operational result. RFC 9614, an Informational IAB-stream publication from July 2024, supplies a vocabulary for testing the difference. It calls the relevant information sets contexts: data, metadata and entities that share access. Privacy improves when no entity other than the client participates in contexts that expose both identifying information — “who” — and activity or content — “what”.

The formulation is deliberately stricter than “the traffic was encrypted” or “we added a proxy”. It asks which entity can observe which facts, what other contexts that entity inhabits, and whether the observations can be joined. A design can be cryptographically correct and still fail this systems test. It can also improve privacy materially without claiming anonymity. The useful task is to state exactly which linkage becomes harder, against which observer, under which operating assumptions.

Contexts, not boxes

A context is not necessarily a server, connection or legal entity. One service can participate in several contexts. Several machines can share one context because their operator aggregates logs or identifiers. Two nominally independent organisations can become one effective observation context through a common processor, shared telemetry platform or contractual data exchange. Conversely, one organisation may impose technical and governance barriers that make a join difficult, although the strength of that barrier must be demonstrated rather than assumed.

This explains why counting proxies is weak assurance. A second hop changes the path, but it does not reveal who controls it, which identifiers it receives or whether its records are linkable to the first hop. Adding contexts can reduce what any one participant sees. It can also add parties whose non-collusion and operational discipline are now necessary. More boxes can mean less concentration of information; they can also mean a larger trust surface.

The central question is therefore not “how many partitions?” It is “what observation can each participant make, and what can it combine?” That question should be answered for application payload, transport and network metadata, authentication state, billing identity, device fingerprints, timing, size, DNS behavior and administrative logs. If the map stops at the protocol headers, it stops before the privacy claim begins.

RFC 6973 gives the broader privacy-threat and data-minimisation vocabulary. RFC 9614 turns that vocabulary into an architectural discipline: separate the material needed to identify a subject from the material that describes the subject's action. The discipline does not abolish every observer. It tries to prevent one observer from possessing the complete relation.

Encryption moves the observer

TLS can keep intermediaries from reading content, but a TLS endpoint can see the plaintext and often the peer network address. Encryption changes who can observe a fact. It does not automatically split “who” from “what”. If the same service terminates encryption, authenticates the account and processes the request, the necessary contexts have already converged.

The same caution applies to tunnels and VPNs. A local access provider may no longer see the final destination in the same way, but the VPN provider can see the client-facing connection and the onward connection. The privacy relation has moved to a new operator. That may be a worthwhile change in the threat model. It is not the disappearance of observation.

Separate connections are equally fragile when they carry a stable token, a distinctive browser or device fingerprint, or an account identifier. RFC 8981 addresses one source of IPv6 address linkability through temporary addresses, but changing an address cannot neutralise identifiers higher in the stack. A privacy review that celebrates rotating network identifiers while preserving a durable application token has partitioned the wrong layer.

RFC 9000 provides the transport context for QUIC; RFC 9180 provides the cryptographic context for hybrid public-key encryption. Both are valuable mechanisms. Neither can decide whether an organisation correlates metadata across roles, how long it retains observations, or whether an application voluntarily places an email address inside the protected payload. Cryptography sets boundaries. Deployment decides who stands on each side.

OHTTP makes the test concrete

RFC 9458 defines Oblivious HTTP. A client encrypts a request to a gateway and passes it through a relay. In the intended split, the relay observes the client connection but not the request content, while the gateway processes the request without receiving the client's direct network address. RFC 9230 applies a related oblivious design to DNS over HTTPS.

This is a meaningful partition. It removes a complete observation from an ordinary endpoint and can make mass linkage more difficult. But the protection is conditional. If the relay and gateway exchange transaction-level logs, their observations can be recombined. If a unique token survives inside the request, the gateway may learn identity from the payload. If message sizes are distinctive and the traffic volume is sparse, timing and size can provide a join key without an explicit identifier.

The correct assurance statement is therefore bounded: the relay does not receive the plaintext request under the protocol; the gateway does not receive the client's direct connection; specified observers must combine additional information or cooperate to reconstruct the relation. That is stronger and more honest than “OHTTP makes users anonymous.” It also tells an auditor what to test.

Tests should generate controlled traffic with varied sizes and intervals, capture observations at each role, and attempt record linkage under the access available to the assumed adversary. They should repeat the exercise when caches are cold, queues build, retries occur and traffic falls back. A privacy result that exists only at steady state is not an operating result.

Privacy Pass exposes the ownership question

RFC 9576 describes Privacy Pass architecture using roles such as origin, client, attester and issuer. The resulting privacy depends on which roles are separated, which identifiers each sees and whether their observations can be correlated. A diagram with distinct role names does not establish distinct control.

If one operator controls the origin and attester, or the attester and issuer, the available joins differ from a deployment with independent operators. Timing can matter even when protocol messages omit a common identifier. A rare attestation immediately followed by a rare redemption can be highly identifying. The privacy claim must describe the deployment model, not merely the protocol family.

This is where corporate structure becomes technical metadata. Beneficial ownership, subcontractors, shared security monitoring, incident-response access and analytics accounts determine whether two roles are truly separate in practice. Legal non-collusion commitments can improve the risk posture, but they need auditability, retention controls and consequences. A policy document cannot erase a shared data store.

Nor should independence be romanticised. Additional providers create availability and security dependencies. Each can misconfigure software, leak metadata or become a coercion point. The operating objective is not maximal institutional multiplication. It is the minimum set of independently controlled contexts that produces a measurable privacy benefit without making the service ungovernable.

Side channels are part of the product

Timing and message size are not implementation trivia. They are observations. A relay that sees a 14-kilobyte request at one moment and a gateway that sees a corresponding arrival shortly afterwards may possess a practical correlator even if both sides use fresh protocol identifiers. Low-volume systems are especially exposed because the anonymity set is small.

Padding can reduce size distinctions. Delays, batching or cover traffic can blur timing. Each mitigation consumes bandwidth, latency, compute or operational clarity. Fake traffic is costly and can itself become patterned. RFC 9614 does not promise a universal setting because the appropriate trade-off depends on the service and threat model.

The absence of such mitigations is not automatically negligence. It is a boundary on the claim. A service may reasonably protect content from access networks while accepting that a powerful observer can perform timing analysis. The failure occurs when marketing says “unlinkable” and the design only says “not visible in one payload.”

Measurements should report the size of the plausible anonymity set, linkage accuracy under realistic traffic, retention windows and how results change during incidents. A median privacy score is insufficient if retries, long messages or regional outages make a minority of users uniquely linkable. Those tails are where an adversary will work.

Fallback is the hidden merger

Privacy-enhancing paths add latency and failure dependencies. Operators therefore build bypasses: direct mode when the relay is unavailable, a single-hop mode during gateway congestion, a diagnostic header for support, or an abuse-control exception that restores client identifiers. These choices may preserve availability or safety. They also change the context map.

A fail-open design can transform a temporary infrastructure fault into identity disclosure. A fail-closed design can deny service and push users toward less trusted alternatives. Neither policy is universally correct. What matters is that the transition is explicit, observable and included in the privacy promise.

The receipt should name the trigger, duration, affected population and information newly visible during fallback. It should distinguish a complete bypass from reduced partitioning. It should show whether data collected during the exception is later joined with ordinary records. Without this evidence, an annual architecture review describes the path used least often precisely when risk is highest.

Abuse controls create a related pressure. Rate limiting, fraud detection and denial-of-service protection often rely on stable network or account signals. Partitioning removes some of those signals. Restoring them through a hidden global identifier defeats the design. The alternative may involve privacy-preserving tokens, per-context limits, aggregation, short retention or accepting more false positives. Those are product and governance decisions, not details to leave to an emergency dashboard.

A privacy receipt has fields

The minimum receipt begins with a context inventory. For each context it lists the data and metadata present, entities with access, the controlling operator, subcontractors, identifiers and fingerprints, retention period, permitted joins and deletion behavior. It identifies cryptographic endpoints rather than merely saying “encrypted”. It records the normal path and every fallback.

The second layer tests independence. Are the operators under common ownership? Do they share administrators, observability systems, support tickets, fraud systems or cloud accounts? Can a single incident commander authorize access to both logs? Which joins are technically impossible, which are contractually prohibited, and which are merely discouraged?

The third layer measures attackability. How accurately can authorised red teams link controlled transactions using timing, size, sequence, geography and rare events? How does accuracy change as the anonymity set grows or shrinks? Do retries, errors and long-lived connections create unique signatures? Can application fields reveal the subject despite transport separation?

The fourth layer covers change. Software releases, provider consolidation, new analytics, revised retention, abuse incidents and emergency bypasses can redraw contexts without changing the public architecture diagram. Privacy partitioning therefore needs continuous configuration evidence, not a one-time certification.

Sources