"Your files never touch our server" is an easy thing for a website to claim. This page explains how that actually works in LocalShare, which parts do involve a server, and where the limits are.
The problem: browsers cannot simply call each other
A web page can open a connection to a server, but two browsers have no way to find each other on their own. Neither knows the other's address, and home routers reject unexpected incoming connections. Something has to introduce them. That introduction is the only job a server needs to do.
Step 1: signaling
When you open LocalShare, the page opens a WebSocket — a connection that stays open in both directions — to the server, and is given a random identifier. When you share a file, the page sends the server a short description of it: name, size and which device has it. The server passes that list to the other devices on your network. The file itself stays where it is.
When another device asks to download the file, the two browsers exchange a handful of small messages through the server. These contain the technical details each side needs to reach the other: which addresses it can be contacted on and which encryption fingerprint it will use. This exchange is called signaling, and it amounts to a few kilobytes.
Step 2: finding a route
Each browser collects a list of ways it might be reachable — its address on the local network and, by asking a public helper called a STUN server, the address it appears to have from the outside. The two browsers then try the combinations until one works. This procedure is called ICE. On a home network the winning route is almost always the direct one, device to device across your own router.
If no direct route can be found — some routers and firewalls block them — WebRTC can fall back to a relay, known as a TURN server, which forwards the data between the two sides. The relay only sees encrypted traffic passing through and cannot read it, but in that case the data does leave the local network on its way.
Step 3: the data channel
Once a route is found, the browsers open a WebRTC data channel between them. WebRTC is the same technology video calls use in the browser; a data channel is its mechanism for sending arbitrary bytes instead of audio and video.
Encryption is not optional in WebRTC. Every data channel is protected with DTLS, a close relative of the TLS that secures HTTPS. The keys are negotiated directly between the two browsers, so the signaling server never has them.
Step 4: sending the file in pieces
The sending browser reads the file 64 KB at a time and writes each piece into the channel. It watches how much data is waiting to go out and pauses when the queue gets long, so a fast disk does not flood a slower Wi-Fi link. The receiving browser collects the pieces, counts bytes to drive the progress bar, and when the total matches the announced size, assembles them and hands the result to the normal download mechanism.
Two practical consequences follow from this design:
- The sender must stay on the page. There is no copy anywhere else to download from.
- Very large files are limited by the receiving device. The browser has to hold the pieces until the file is complete, so a phone with little free memory or storage may struggle with a file of several gigabytes where a laptop would not.
What the server sees, and what it does not
The LocalShare server sees that a browser connected and from which IP address, which it uses to decide which devices are on the same network. It handles the list of shared file names and sizes so other devices can display them, and it relays the signaling messages. It does not receive file contents, and it has no way to know whether a shared file was ever downloaded, because that happens on a connection it is not part of.
File listings are held in memory and expire after 72 hours. The privacy page describes the small amount of anonymised usage data that is kept.
What this does not protect against
Peer-to-peer transfer removes the cloud from the picture; it does not make the local network trustworthy. Anyone on the same network who opens the page can see and download what is being shared. On a home network that is the point. On a shared network — an office, a student house, a café — only share what you are happy for the other people there to have, and stop sharing when you are done.
Why not just use a server?
Routing files through a server would be simpler to build and would work between any two devices anywhere. It would also mean paying for the bandwidth and storage of every transfer, holding other people's files, and making every transfer as slow as the sender's upload speed. Keeping the server out of the data path is what makes it possible to run a tool like this for free.
Open LocalShare