↔P2Priv 1 entries · updated 2026-09-29

What Another Peer Can See — and What It Cannot

A direct peer-to-peer connection exposes an IP address and connection details, but not automatically your name or exact location. Here is the boundary.

P2Priv Editorial Team · 3 min read

A peer-to-peer connection is direct by design. The other device needs an address to send data back, so the person or service at the other end can normally see the public IP address used for the connection. That is useful information, but it is not the same as seeing your name, home address or everything you do online.

Understanding the boundary matters because both extremes are wrong: a public IP is not harmless, and it is not a magic identity card.

What a peer normally receives

At minimum, a peer sees the source IP address and source port of the traffic reaching it. The protocol may expose more:

  • A BitTorrent peer can see the peer ID, supported extensions and which pieces of a file you request or offer.
  • A WebRTC peer can receive network candidates used to establish the call. Modern browsers restrict some local-address exposure, but the public connection path remains visible unless traffic is relayed.
  • A sync application can expose its application version, device identifier or configured device name, depending on the protocol and settings.

Public swarm trackers and distributed hash tables may also record that an IP address announced interest in a particular info-hash. That observation can persist after you disconnect if somebody logs it.

What an IP address can reveal

An IP lookup can usually identify the internet provider and country. It may estimate a region or city, but consumer IP geolocation is not a precise map pin. Addresses are reassigned, mobile traffic may exit elsewhere, and carrier-grade NAT can put many households behind one public address.

Connecting an IP address to a subscriber generally requires the provider’s account records for a specific time. Those records are not available to an ordinary peer, though legal processes and data leaks can change who gets them.

An observer can still combine an IP address with other clues. A distinctive username reused across services, a device name sent by an application, or a link opened in the same browser can turn a rough network clue into a stronger association. Privacy is therefore about limiting combinations, not only hiding one field.

What the peer does not automatically see

A direct connection does not by itself give the other peer:

  • your browsing history outside that connection;
  • files you did not make available through the application;
  • your exact physical address;
  • your real name or account with the internet provider; or
  • the contents of properly end-to-end encrypted traffic.

Software vulnerabilities, unsafe sharing settings and metadata can reveal more, but those are separate risks from the network address needed to make the connection.

Which controls change the view

A relay puts an intermediary in the data path. The other peer sees the relay’s address, while the relay can see the endpoints and may be able to observe unencrypted traffic. WebRTC TURN servers and sync-tool relays work this way.

A VPN creates an encrypted tunnel from your device to a VPN server. The peer sees the VPN server’s address. Your internet provider sees a connection to the VPN, and the VPN provider occupies the position that your provider previously held. A VPN therefore changes who must be trusted; it does not remove trust.

Application settings can prevent accidental exposure outside the protected path. A BitTorrent client can often be bound to the VPN interface so it stops transferring if that interface disappears. Browser controls can limit WebRTC address candidates. A sync tool may allow relay-only connections.

A proxy may cover only one application’s traffic and may not carry every protocol it uses. Verify the actual connection rather than assuming a proxy setting covers DNS, trackers, DHT and peer traffic.

Test the path, not the marketing claim

Before sharing anything sensitive, establish the connection and inspect what address the remote service reports. Repeat after disconnecting and reconnecting the privacy tool. For software with multiple traffic paths, check each one. The useful question is concrete: which address and metadata reach this peer in this configuration?

Another peer can normally see the address that talks to it. Relays and VPNs replace that address with theirs; careful settings prevent a fallback from quietly revealing the original. That is meaningful privacy, but it is not anonymity by itself.