Direct, Not Relayed: How WebRTC Actually Secures a Peer-to-Peer File Transfer

"End-to-end encrypted" gets printed on a lot of file-sharing products, and it rarely comes with an explanation of what's actually encrypting what, or who could theoretically still get in the middle. WebRTC — the browser technology behind video calls, and increasingly behind direct file transfer — is worth understanding on its own terms, because the encryption isn't a feature the app author bolted on. It's mandatory at the protocol level.

What WebRTC actually is

WebRTC (Web Real-Time Communication) is a set of APIs and protocols, standardized jointly by the W3C and the IETF, that lets two browsers or applications exchange audio, video, or arbitrary data directly — without routing that data through a server in the middle. It shipped as a W3C Recommendation in January 2021, and every major browser has implemented it for over a decade at this point.

Two machines "directly" connected over the public internet is a harder problem than it sounds like, because most consumer devices sit behind NAT (network address translation) and don't have a public IP address a peer can just dial. WebRTC solves this with ICE (Interactive Connectivity Establishment): each side gathers a list of possible network paths — its local address, its address as seen from outside its router (found via a STUN server), and, as a fallback, a relayed path through a TURN server — and the two sides negotiate the best one that actually works. When a direct path is available, which is most of the time on modern networks, that's the one used, and no further traffic touches any third party.

The part that's mandatory, not optional

Here's the detail that matters for anyone thinking about whether to trust a WebRTC-based tool with a sensitive file: encryption in WebRTC isn't a mode you choose. The specification — RFC 8827, "WebRTC Security Architecture" — requires every media and data channel to be encrypted, with no unencrypted fallback defined anywhere in the protocol. Concretely:

• The two peers perform a DTLS (Datagram Transport Layer Security) handshake directly with each other, once ICE has found a working network path. This negotiates a fresh set of encryption keys between exactly those two machines — nobody else, including whatever server helped them find each other, is party to this handshake.
• Arbitrary data (files, in our case) travels over SCTP running on top of that DTLS channel, so it's encrypted the same way voice and video are.
• There is no protocol-level way to negotiate this down to plaintext. An application built on WebRTC would have to deliberately re-implement its own transport outside the standard APIs to skip it — it can't happen by accident or by a misconfigured flag.

This is a meaningfully different security model from "we encrypt it before upload" (encryption chosen and controlled by the app vendor, terminating at their server) or "TLS to our API" (which secures the hop to the vendor, not between the two people actually exchanging the file). With WebRTC, the cryptographic session is between the two endpoints, full stop.

So what's the signaling server for?

Two machines that don't know each other's network address yet can't perform ICE or a DTLS handshake — they need to first exchange some setup information (session descriptions, candidate addresses) through some channel. That job belongs to a signaling server, and it's worth being precise about what it does and doesn't see: it passes along connection metadata so the two sides can find each other, and then it's out of the picture. It is not a party to the DTLS handshake and never receives the file itself, or even the key to open it.

That's a real architectural distinction from a relay or cloud-storage model, where the file has to reach the intermediary's server before it can reach the other person — which means a copy exists there, even briefly.

Where this shows up in Privatta

This is the exact model Privatta uses for transfers over the internet: the signaling server introduces two peers and gets out of the way, and the transfer itself runs over WebRTC's own DTLS encryption between the two machines — the same transport security behind browser video calls, not a custom protocol of our own. On top of that, connecting requires a one-time key the host generates and shares directly, plus credential checks, with repeated failures locking the connection. The signaling relay itself keeps one in-memory table of pending pairings and nothing else — no database, no disk write — and it's open source, so that claim doesn't have to be taken on faith.

None of this is Privatta-specific magic; it's what WebRTC gives any application built on it correctly. If you're evaluating a "peer-to-peer" or "direct transfer" product, the actual dividing question to ask is whether it's really using this model — direct, mandatory encryption, no copy at rest anywhere — or whether "P2P" is being used loosely to describe a service that still stores your file on a server in between.

Sources: RFC 8827 — WebRTC Security Architecture · W3C WebRTC 1.0