IPFS Bitswap Privacy Leak: Want-List Metadata (2D)

Swarm Configuration

PUBLIC DHT SWARM

Trusted swarm peers 10

Auto want-list rate 1.0 / s

Publish CID to public DHT

Live Readouts

Connected peers

CIDs broadcast

CIDs leaked

Privacy score

100%

How it works

IPFS retrieves data by content hash (a CID), not by server address. To find a block, a node's Bitswap protocol sends a WANT-HAVE message to every peer it is directly connected to — this is a metadata broadcast, not a data transfer. If none of them has the block, the node falls back to a Kademlia DHT lookup, which can reach far beyond the immediate swarm and publishes a public provider record mapping CID → your peer ID.

Leak(event) = 1  if  eavesdropper ∈ connected_peers
Leak(event) = 1  if  publish_to_public_DHT = true
Privacy score = 100 × (1 − leaked / broadcast)

Encrypting the file's contents does not hide this. The CID and the fact that you asked for it are visible to anyone who shares a connection with you or watches the DHT — this is a classic access-pattern / metadata leak, distinct from confidentiality of the payload itself.

Public DHT swarm — any peer, including an observer, can connect and see your want-lists.
Private network (swarm.key) — a pre-shared secret (libp2p "pnet") is required just to complete the handshake; an untrusted peer is rejected before it can see anything, closing the direct-peer leak.
Publish to public DHT — even inside a private swarm, announcing a provider record on the public DHT re-opens the leak, since that record is globally readable. This is the single most common IPFS privacy misconfiguration.

Defensive takeaway: private networks protect swarm membership, but only disabling public DHT announcements (or using a private DHT / delegated routing) protects the request metadata itself.

Trusted swarm peer Eavesdropper Public DHT You (requester)

Drag to pan · scroll to zoom