Skip to main content
Your files are encrypted on your device and decrypted on the other person’s. Nothing in between can read them, and that includes Floe’s own servers. There is nothing to switch on. It is not a mode, an upgrade, or a setting. Every transfer works this way, direct or relayed, on floe.one or on an instance you run yourself.

​
Three things that follow from that

The keys exist only on the two devices. They are generated fresh for each transfer, live in the two browsers or apps involved, and are thrown away when the connection closes. There is no key server, no escrow, and no recovery: once a transfer is over, that transfer’s keys are gone and cannot be reconstructed by anyone, Floe included. The servers handle the introduction, not the content. The signaling server passes connection details between the two devices for a few seconds and then plays no further part. It is not on the path the file takes. When a relay is involved it is on the path, but only ever carrying encrypted packets it has no way to open. Self-hosting does not change any of this. The encryption is a property of the connection between the two devices, not of who runs the server. If you run your own instance you get the same guarantee, and you also stop depending on anyone else for the one part that is trusted, which the next section explains.

​
What it does not protect against

Encryption answers “can anyone in the middle read this”. It does not answer every question, and the honest limits are worth knowing rather than discovering. The one that matters most: the two devices agree on keys by exchanging certificate fingerprints, and those fingerprints travel through the signaling server. A server that wanted to could hand each side a fingerprint it controls, sit in the middle, and read everything. This is true of every application built on WebRTC, and the usual defense is a short code the two people compare out of band. Floe computes that code internally but no client shows it today. Read Known limitations for that and the seven others in plain language. A privacy claim is worth more when the exceptions are published alongside it.
Floe uses WebRTC data channels, which run SCTP over DTLS. DTLS is TLS adapted for datagrams: the same cipher suites and the same handshake, over a transport that does not guarantee ordering. This is distinct from DTLS-SRTP, which is what WebRTC uses for audio and video.Each peer generates a certificate and key pair for the session. The fingerprints of those certificates are carried in the SDP offer and answer during setup, and the DTLS handshake verifies the certificate it receives against the fingerprint it was promised. An attacker sitting on the network path cannot substitute a certificate, because they cannot also change the fingerprint that arrived through the signaling channel. An attacker who controls the signaling channel itself can, which is the limitation described above.Keys are ephemeral and per-session. They are created when the connection is created and discarded when it closes.Floe adds no encryption layer of its own on top of this, and computes no hash of file contents. Integrity in transit comes from DTLS; integrity of the finished file is a byte-count check against the size the sender announced. See the transfer protocol reference.