Most video conferencing trusts a central server: it receives everybody’s video and audio, distributes it, and decides who gets in. Briefing turns that around. The guiding idea:
The server brokers, but you don’t have to trust it. A compromised or failing server may disturb a call - but it can never read it, never join it, never impersonate anyone in it, and never end it.
This page explains how that works technically. For how to use Briefing, see the help.
In short
| Typical video service | Briefing | |
|---|---|---|
| Path of video and audio | through a central media server (SFU) | directly from browser to browser |
| Encryption | usually only up to the server, end-to-end often optional | always end-to-end |
| Who knows the key? | often the provider | only whoever has the link |
| Who decides who gets in? | the server | the participants in the room |
| Does the server know the room name? | yes | no |
| Call during a server outage | drops | keeps going |
| Account, app, tracking | usually required or present | none of them |
| Recording on the server | often possible | nothing is stored |
Direct instead of through a media server
Large video services send everybody’s video and audio to a central media server (a Selective Forwarding Unit, SFU for short), which distributes the streams to everyone else. That scales well for big meetings, but it comes at a price: transport encryption ends at the server. It has access to all media - whether it uses it is a matter of trusting the provider.
Briefing connects the participants directly with each other (a so-called mesh) using WebRTC, the real-time communication standard built into every modern browser. Video and audio are encrypted between the browsers with DTLS-SRTP; chat, files and documents are additionally encrypted with the room key. There is no point where everything comes together.
To be honest: in a mesh everybody sends their video to everybody else, so upload grows with every additional person. Briefing is therefore meant for small groups, and it keeps the cost down by sending each receiver only as much video quality as it currently displays - a thumbnail gets a small picture, a hidden tab almost nothing.
When a direct connection doesn't work
Strict firewalls sometimes prevent a direct connection. Then a relay server (TURN) steps in. It only passes on packets that are already encrypted and cannot read any of them - unlike a media server.
The key is in the link
A Briefing room is a link with two parts: the room name and - after the # - the password. Browsers never send the part after the # to the server. Briefing builds on that:
- From the password the browser derives the room key (PBKDF2 with 600,000 iterations, then AES-GCM). Everything that passes through the server or is exchanged between participants is encrypted with it. Every message is bound to its purpose and direction, so a captured packet cannot be replayed elsewhere.
- From name and password the browser computes a room id. That is all the server ever sees. It cannot be reversed, and without the password nobody can find a room, occupy it, or even check whether it exists.
So any number of separate rooms can exist under the same name. A wrong password doesn’t lead to a locked door, but into an empty room.
The participants decide who gets in
Before two browsers can connect directly, they have to exchange connection details first - so-called signaling. That takes a server where you find each other. With Briefing, it only ever sees ciphertext:
- Ben enters the room and sends the room id and a join message encrypted with the room key.
- The server cannot read it. It passes it on unchanged to Anna, who is already in the room.
- Anna decrypts the message and checks that it belongs to this room, that it is fresh, and that it names exactly the participant id Ben is using. Nobody can take over someone else’s identity this way.
- Only if all of that checks out is Ben admitted.
- Anna and Ben exchange their connection offers (SDP, ICE) through the server - encrypted and bound to their direction.
- The direct connection is up.
If a manipulated server lets someone in anyway, it gains nothing: without the room key there is nothing to decrypt and no connection to set up.
The call doesn’t need the server
Once connected, further signaling (for example when someone shares their screen) runs directly between the browsers too. The server no longer learns about it. A restart, an update or an outage of the server therefore doesn’t interrupt a running call. When the server is back, everyone quietly reconnects to it. It is only needed to enter a room.
Safety codes: is someone in between?
What if someone with access to the server and the room link put themselves between two participants? That’s what safety codes are for: for every direct connection Briefing shows six symbols, computed from the certificates the two browsers actually use.
- If both are connected directly, both see the same symbols.
- If someone sits in between, each side actually has a connection to the attacker - and the symbols differ.
You’ll find them under Settings → Safety codes. Simply read them out to each other at the start of a confidential call.
Without any server
Taken to its logical end, Briefing doesn’t even need a server to find each other. In the experimental Connect without server mode you exchange invitation and answer yourselves, by QR code or messenger:
- Anna creates an invitation. It contains the room password and Anna’s network addresses.
- Ben opens it and sends back an answer, encrypted with the room key.
- Anna and Ben are connected directly. If Ben now invites Carla, he introduces her to Anna over the existing connections, so everybody is connected with everybody.
No signaling server takes part. Because the invitation contains the password and network addresses, it belongs only in the hands of the invited person. The safety codes reveal whether anyone altered the invitation on the way.
What the server knows - and what it doesn’t
| The signaling server sees | The signaling server does not see |
|---|---|
| the room id (irreversible) | the room name |
| random participant ids chosen by the browser | names or profile pictures |
| encrypted connection setup messages | their content |
| connection times and IP addresses (the network needs them) | video, audio, chat, files, documents |
| the password or the room key |
Usage statistics store rooms only as salted hashes and participants not at all. Push notifications carry only the room id. All logs rotate. Details are in the privacy policy.
Verifiable, not just promised
- Encryption in the browser: encryption and decryption are done by your browser’s built-in cryptography (Web Crypto). The browser’s developer tools let you watch that only ciphertext goes to the server.
- Strict security policy (CSP): the browser runs only code the instance itself serves - no scripts loaded from foreign servers, no web fonts, no CDN.
- Code fingerprint: the start page shows a fingerprint over the app files your browser actually uses. It can be compared with the fingerprint published for the release.
- Updates only on click: a new version never silently takes over a running tab.
- Self-hosting: Briefing ships as a single Docker image, and every feature works without our infrastructure. The official instance runs exclusively in data centers in Germany.
The limits
No system comes without trade-offs. These are worth knowing:
- The link is the key. Whoever has it gets in. Send it only through channels you trust, and set a new password when in doubt.
- Direct connections reveal IP addresses. For browsers to reach each other directly, participants learn each other’s network addresses.
- Small groups. Without a media server, upload grows with every person. For large conferences another tool is a better fit - see Briefing compared.
- Metadata. Briefing’s server, too, sees when which IP address connects to a room id - just not what it’s about.
- Media server as an option. Operators can use a LiveKit media server instead of the mesh. Admission, chat and data stay end-to-end encrypted, but video and audio then pass through that server, and safety codes are not available.