Skip to content

Broker Visibility Partitioning

Interposition protocol — instantiates Side-Channel Leakage Containment

Splits handling across intermediaries so no single broker sees enough metadata to link the protected fact — each hop learns only its own slice.

Some leaks come not from any one output but from one party seeing enough to correlate — the same server that knows the sender also knows the recipient. Broker Visibility Partitioning interposes two or more intermediaries and divides the observable metadata among them, so that reconstructing the protected linkage would require collusion across parties none of which individually holds it. Its defining move is architectural: it does not remove metadata from any message (that is Metadata Minimization Filter's job) but distributes visibility so the correlating key never rests in one place. Where a filter deletes a field, a partition ensures no single observer holds both halves of the pair.

Example

A messaging provider wants a guarantee that no single server it runs can state "Alice messaged Bob." It routes each message through a sequence of independently operated relays: the entry relay sees Alice's identity but only an opaque next-hop token; a middle relay sees neither endpoint; the exit relay sees Bob but not Alice. The sender–recipient linkage — the protected fact — exists nowhere in one relay's view. Only collusion across all hops could rejoin it, and the relays are deliberately run by separate operators to make that hard. This is the containment logic of mix networks and onion routing.[1]

How it works

  • Interpose independent parties. Insert two or more brokers whose operators (and ideally jurisdictions) don't share trust.
  • Assign disjoint metadata partitions. Give each broker exactly one slice of the metadata — identity, or routing, or timing — never the combination that links.
  • Keep the linking key uncoexistent. Ensure the field that correlates the protected pair is never present at a single party at a single time.
  • Constrain per-hop retention. Each broker may keep only its slice; shared logs or a common telemetry sink would silently rejoin the partition.

Tuning parameters

  • Number of hops — more intermediaries strengthen unlinkability but add latency and operational complexity.
  • Partition boundary — which metadata field is treated as the linking key to split on (identity vs. routing vs. timing); the wrong cut leaves a joinable pair.
  • Non-collusion strength — independent operators, separate jurisdictions, or merely separate processes; the whole guarantee rests on how independent the parties truly are.
  • Per-hop retention — how much each broker may log; tighter retention protects the partition, looser aids debugging.

When it helps, and when it misleads

Its strength is defeating a single-vantage observer — including an insider at one broker — because no one seat holds the correlatable whole. It misleads when the independence assumption is weaker than believed: colluding operators, or a global observer who correlates arrival timing across hops, can rejoin what the partition split, which is why it pairs with Batching and Delayed Release to blur the cross-hop timing. The classic misuse is partitioning who-sees-what while quietly funneling all hops' logs into one shared analytics backend that reunites the metadata. The discipline is to verify non-collusion and to prevent any out-of-band channel — shared logs, telemetry, backups — from re-linking the slices.[1]

How it implements the components

Broker Visibility Partitioning fills the visibility-distribution components — the ones an architecture, not a filter, produces:

  • broker_metadata_partition — the split itself: the assignment of disjoint metadata slices across non-colluding brokers.
  • metadata_visibility_policy — the per-hop rules governing exactly what each broker may see and retain.

It does not strip metadata from an individual output — field-level removal is Metadata Minimization Filter's — and it does not isolate shared compute resources, which is Cache Partitioning or Flush Rule's shared_resource_isolation_boundary.

Notes

The guarantee is only ever as strong as the non-collusion assumption — a single operator, shared infrastructure, or a common log sink collapses the partition. Partitioning is therefore an architecture decision, not a config toggle: it must be designed into where the trust boundaries fall, not bolted on afterward.

References

[1] Mix networks — David Chaum's design in which messages pass through a chain of intermediaries that each re-encrypt and reorder traffic so no single node links sender to recipient; onion routing (as in Tor) is a descendant. The containment property is unlinkability under non-collusion, not secrecy of content. ↩