Transit-protected vs sealed rooms: how sovereign video meetings work

“End-to-end encrypted” is a phrase that gets attached to a lot of meeting products, often loosely. For a government or regulated buyer, the distinction between a room the server can see and a room it cannot is not marketing: it decides what a compromise of the server would expose. Here is how the two models differ, stated precisely.

The server-trusted model, or transit protection

In the common model, media is encrypted in transit between each client and the server, but the media server terminates that encryption so it can route, mix, record, or transcribe the streams. The server can see the content. That is not a flaw; it is what makes server-side recording and transcription possible, and it is appropriate for a great many meetings. But it does mean the server sits inside your trust boundary: whoever controls the server can, in principle, see the meeting.

The end-to-end model, or sealed

In an end-to-end encrypted model, the media is encrypted by the participants for the participants, and the server only relays ciphertext it cannot read. The server does not hold the media-decryption keys in this model. Endpoint compromise, participant capture, and the integrity of client software remain separate risks. The trade is capability: the server cannot mix, record, or transcribe what it cannot see, so those features move to the client or are simply unavailable.

Classification belongs on the meeting, not the user

Whether a meeting is server-trusted or sealed should be a property of the meeting, fixed when it is scheduled, not a per-participant toggle that can drift. Getting this wrong is exactly how a meeting everyone believed was confidential quietly turns out to have been server-trusted all along.

Reading the fine print on “end-to-end”

When a product claims end-to-end encryption, three questions separate a precise claim from a loose one. Which rooms: all of them, or a specific class? At what tier: a hardened native client, or browser-tier cryptography? And at what assurance: independently reviewed, or self-assessed? A browser-tier end-to-end path is real, but it has a different assurance profile than a reviewed native client, and an honest product says which it is offering.

How Dorbar draws the line

Dorbar makes the two classes explicit and fixes them at scheduling. Official rooms are server-trusted and protected in transit; the media server handles the streams, which is what lets Official rooms be recorded and transcribed. The Sealed-room end-to-end encryption path is built but dormant in the default deployment. Its browser implementation is rated medium assurance pending external cryptographic review; it is not a live option for sensitive meetings today. Official rooms are never described as end-to-end encrypted. The whole platform runs inside your own boundary, in Bengali or English at parity.