LocalSend Under the Hood: LAN Discovery, Token-Based Transfer, and a Default-HTTP Gotcha
The discovery and consent flow LocalSend uses is the same pattern behind AirDrop and Nearby Share, but it works across every desktop and mobile OS and even from a browser. For anyone building LAN transfer tools, the default unencrypted HTTP in the share link is a concrete security decision: it works, but it exposes the transfer unless you enable HTTPS and solve certificate trust.
LocalSend v1.18.2 works by having each device broadcast its name and connection details on the local network, then having peers connect back to verify reachability and (if encrypted) check certificates before they appear in the device list. The transfer itself separates consent from content: the sender offers a file manifest, the receiver approves per-file, gets a session token for each allowed file, and only then does the sender push actual data. Integrity checks and duplicate upload blocks guard the transfer, and the receiver handles only one sender at a time, which serializes uploads from multiple devices.
The app's in-app browser share defaults to HTTP, not HTTPS, unless you flip an encryption switch and deal with certificate warnings. The separate Web client uses a different discovery path and is not subject to that default. Common failure points include router AP isolation, Windows network classification, Mac/iPhone local network permissions, and proxy or VPN interference; port 53317 must be open for TCP and UDP. The author's own Web client test hit a proxy problem, and the official troubleshooting list suggests temporary encryption or band/position checks when transfers are slow.
LocalSend's design decouples approval from data transfer: the receiver can veto specific files before any content moves, a privacy pattern worth reusing in other file-sharing tools.
The default HTTP in the share link is a deliberate convenience/security trade-off; the article confirms it from source and tests, meaning anyone wrapping this tool must either force HTTPS or make the risk explicit to users.
The one-sender-at-a-time rule makes LocalSend a home tool, not a shared drop-off service; scaling it to multiple concurrent uploads would require a different receiver architecture.