Proximity Networking Technologies

This section covers the physical-layer technologies that enable device-to-device communication without internet infrastructure.

Bluetooth Low Energy (BLE)

BLE is the most promising transport for proximity discovery and short-range communication on modern smartphones.

How BLE discovery works:

  1. Advertising: A device broadcasts small packets (up to 31 bytes, or 255 bytes with extended advertising in BLE 5.0) at configurable intervals
  2. Scanning: Nearby devices listen for advertisements and filter by service UUIDs
  3. Connection: A "central" device initiates a connection to a "peripheral"
  4. GATT exchange: Connected devices read/write data through the Generic Attribute Profile

Key specifications:

Privacy considerations for BLE:

For a detailed security threat analysis of BLE relay attacks, fingerprinting, and platform surveillance, see Location APIs & Security.

Platform APIs:

Privacy-enhanced BLE discovery pattern:

1. Device advertises a rotating, unlinkable beacon ID
2. Nearby device scans and detects the beacon
3. Devices establish BLE connection
4. Over the connection, devices perform a cryptographic handshake:
   - If they are existing contacts: mutual authentication using stored keys
   - If they are strangers: exchange ephemeral public keys for initial contact
5. Authenticated contacts proceed to message sync
6. Strangers see each other as "someone nearby" — no identity revealed until deliberate introduction

NFC (Near Field Communication)

NFC is ideal for the initial trust establishment moment — the "tap to connect" gesture.

How it works:

What to exchange via NFC tap:

NDEF Record:
  - Application ID (to launch the app if not running)
  - Ed25519 public key (32 bytes)
  - Ephemeral Diffie-Hellman public key (32 bytes)
  - Optional: user-chosen display name (encrypted to recipient)
  - HMAC for integrity verification
Total: ~150 bytes — well within NFC capacity

Privacy strengths:

Limitations:

NFC vs QR code for trust establishment:

NFC Tap QR Code Scan
Range ~10cm (touch) ~0.5–2m (visual)
Speed Instant 2–5 seconds
Both devices active? Yes (P2P) or one passive (HCE) One displays, one scans
Relay attack resistance Excellent (range too short) Moderate (screen could be relayed)
Device support Most Android, limited iOS Universal (camera + screen)
User gesture Natural (tap) Slightly awkward (point camera)

Recommendation: Support both. NFC as primary on Android, QR code as universal fallback.

WiFi Direct / Wi-Fi Aware

Higher-bandwidth alternative to BLE for when devices need to exchange larger amounts of data.

WiFi Direct:

Wi-Fi Aware (Neighbor Awareness Networking / NAN):

Privacy concerns with WiFi:

Platform Frameworks

Apple Multipeer Connectivity (iOS/macOS):

Google Nearby Connections (Android):

For a cross-platform, privacy-first app: These platform frameworks are useful references but cannot be relied on directly. A custom protocol over BLE (with WiFi Direct escalation for bulk data) provides the most control and cross-platform reach.

Local File Transfer: UX Precedents

A growing ecosystem of privacy-respecting local network file sharing tools demonstrates that users accept — and prefer — proximity-based transfer when the UX is right. These are not messaging protocols, but they validate our transport model and offer implementation lessons.

LocalSend

localsend.org · GitHub

Open-source AirDrop alternative using REST API over HTTPS on local WiFi. Devices discover each other via UDP multicast. No internet required, no accounts, no cloud.

PairDrop

pairdrop.net · GitHub

Browser-based AirDrop-style file sharing using WebRTC for P2P transfer and WebSockets for signaling. Improved fork of Snapdrop. Works over local WiFi or temporarily paired rooms.

Magic Wormhole

magic-wormhole.io · GitHub

CLI tool for securely transferring files between any two computers using a short human-readable code ("7-crossbow-clockwork"). Uses PAKE (Password-Authenticated Key Exchange) to establish a shared secret from the code, then encrypts the transfer with NaCl.

OnionShare

onionshare.org · GitHub

Tor-based file sharing and chat tool. Creates a Tor hidden service to host files; recipients access via .onion address. Strong anonymity and censorship resistance.

croc

schollz.com/tinker/croc · GitHub

Command-line tool for encrypted P2P file transfer using a relay for NAT traversal. Uses PAKE for key agreement (same concept as Magic Wormhole but different relay model).

Proximity Transfer Pattern Summary

All these tools converge on the same architecture our proximity layer needs:

1. Discovery   — UDP multicast / BLE advertising / user shares code
2. Pairing     — fingerprint verification / QR scan / PAKE code exchange
3. Channel     — encrypted P2P (WebRTC / BLE GATT / TLS-pinned HTTP)
4. Transfer    — data exchange
5. Termination — ephemeral session, no persistent server state

The UX innovations most relevant to our app:

┌─────────────────────────────────────────────┐
│            Application Layer                 │
│  (message sync, feed replication, UI)        │
├─────────────────────────────────────────────┤
│         Transport Abstraction Layer          │
│  (unified API regardless of physical layer)  │
├──────────┬──────────┬──────────┬────────────┤
│   NFC    │   BLE    │  WiFi    │   Tor      │
│  (trust  │ (discovery│ Direct  │  (optional │
│   est.)  │  + sync) │ (bulk)  │   online)  │
└──────────┴──────────┴──────────┴────────────┘

Priority (offline-first):
  1. NFC → initial key exchange (tap to connect)
  2. BLE → discovery + lightweight message sync
  3. WiFi Direct → bulk data transfer when needed
  4. Tor → optional online relay (user must opt in)

For platform-specific API details and background scanning restrictions, see Location APIs & Security.

Updates (2025–2026)

Bluetooth 6.0: Channel Sounding Adds Relay-Attack-Resistant Ranging

Bluetooth Core 6.0 (released September 2024, devices shipping 2025) introduced Channel Sounding, a standardised sub-metre ranging mechanism using Phase-Based Ranging (PBR) and Round-Trip Timing (RTT). The RTT component is specifically designed to resist relay attacks: randomised transmission patterns (seeded by a DRBG) force attackers to process signals in real time, while an on-device attack-detector provides likelihood metrics to the application layer. Accuracy is ±20 cm in early implementations, effective range reaches ~150 m at max power.

Design impact: Channel Sounding provides a cryptographic complement to NFC for verifying physical proximity during BLE connection establishment — a stronger relay-attack mitigation than RSSI alone. The Pixel Watch 3 was among the first widely-reported devices to expose Channel Sounding capability (June 2025); broad Android handset support is still emerging.

Bluetooth 6.1: Randomised RPA Timing Closes MAC Rotation Correlation Window

Bluetooth 6.1 (released May 7, 2025) introduced one focused change: Randomised Resolvable Private Address (RPA) Updates. Previously, RPAs rotated on a fixed 15-minute timer, creating a predictable correlation window enabling long-term device tracking. 6.1 offloads RPA generation to the Bluetooth controller, randomising the rotation interval between 8–15 minutes (configurable 1 s–1 hr), eliminating the timing side-channel without waking the host CPU. No silicon vendors have announced 6.1-capable chips yet; realistically the first hardware will not ship before 2026. Our transport stack should design for 6.1 behaviour but not depend on it.

NFC Forum Release 15: Extended Operating Range

NFC Release 15 (announced June 2025, certification programme launched October 2025) extends the NFC operating volume from 0.5 cm to 2 cm. The tap-to-connect gesture remains highly relay-attack-resistant (2 cm is still essentially touch-range), but the change may affect UX assumptions around accidental activation in crowded spaces.

Apple Wi-Fi Aware Framework (iOS 26 / WWDC 2025)

⚠ Contradicts existing content: The existing page states "iOS does not expose Wi-Fi Aware APIs." Apple announced a first-party Wi-Fi Aware framework at WWDC 2025, shipping with iOS 26. The framework exposes the Wi-Fi Alliance NAN standard for peer-to-peer discovery and direct connections without an access point, using DeviceDiscoveryUI, AccessorySetupKit, and the Network framework. Connections operate simultaneously alongside the device's existing Wi-Fi network and are authenticated and encrypted at the Wi-Fi layer.

Cross-platform caveat: iOS 26 ↔ Android Wi-Fi Aware interoperability requires Wi-Fi Aware Specification v4.0 pairing support on the Android side. As of mid-2025, only the Samsung Galaxy S25 is confirmed compatible; Pixel 9 and Xiaomi 14 series are not. Wi-Fi Aware is a strong future transport candidate for iOS-to-iOS bulk data sync once install base reaches iPhone 12+ saturation, but BLE must remain the universal discovery layer in the near term.

Apple Network Framework Supersedes Multipeer Connectivity

Apple's developer support team now explicitly recommends migrating from Multipeer Connectivity to Network framework, citing unfixed bugs, no Swift concurrency support, poor throughput, lack of flow control, and mandatory P2P Wi-Fi activation. The replacement path uses NWBrowser + NWListener for Bonjour-based peer discovery and WebSocket/QUIC for transport, with TLS-PSK as the recommended security model for P2P environments without PKI infrastructure. Multipeer Connectivity should be treated as a temporary measure rather than a long-term API choice.

LocalSend v1.17.0: Security Fix and Interface Filtering

LocalSend v1.17.0 (February 2025) patched a path traversal vulnerability and added network interface filtering — relevant to multi-homed devices where isolating discovery to a specific interface (e.g., a BLE-tethered subnet) is desirable. A forthcoming WebRTC-based transport layer was flagged as in progress, which would allow direct P2P connections through NAT without a relay.

USENIX Security 2025: BLE Proximity Tracking Vulnerabilities

A 2025 USENIX Security paper reverse-engineered Apple Find My and Samsung Find My Mobile, uncovering seven new vulnerabilities — four assigned CVE/SVE identifiers, three rated high severity. The vulnerabilities involve identifier correlation across the advertisement and application layers, showing that MAC rotation alone is insufficient when higher-layer identifiers remain stable. This reinforces the existing guidance that advertisement content must use rotating, unlinkable identifiers throughout the stack, not just at the MAC layer.