Security model
The server holds ciphertext. Only the room holds keys.
Ollasync assumes the network and the operator are untrusted. Here is exactly how confidentiality is enforced — not promised.
Keys are born in your browser
Your identity and media keys are generated client-side. Private keys never leave the device in plaintext.
One key per room
Each room has a single key, generated in your browser and shared only through the invite link — it is never sent to our servers.
Every track is sealed with that key
Chat, audio, video and screen share are each encrypted with the room’s key (AES-GCM). The relay and the SFU only ever forward ciphertext.
The server relays ciphertext
The delivery service and the media SFU forward encrypted frames they cannot decrypt. We verify this end-to-end in tests, not in a policy PDF.
Guarantees
What that buys you
🔒 Confidentiality
The relay and SFU never see plaintext. Even a full server compromise yields ciphertext, not conversations.
🧪 Verifiable, not asserted
A participant with the wrong key decodes zero frames and reads zero messages — a property we test end-to-end, not a line in a policy PDF.
🔑 Client-side keys
Each room’s key is generated in your browser and travels only in the invite link. It never reaches our servers, so we can’t hand over what we don’t hold.
🌍 Data residency
Shared cloud is EU-hosted (Frankfurt). Pin hosting and the media SFU to Switzerland or your own region on a single-tenant deployment, or self-host to keep everything in your perimeter.
📜 Tamper-evident audit
Room activity is logged in a signed trail — useful for diligence and compliance without exposing content.
🚫 No metadata theatre
We minimise what’s collected and are explicit about what the relay can and cannot see.
🔐 Access & identity
Per-org SSO (OIDC & SAML), passkeys and TOTP 2FA. Identity is decoupled from the server-blind media plane — the keys to your conversations never touch it.
FAQ
Straight answers
Can Ollasync read my messages or calls?
No. We never hold a decryption key. A message stored on our relay is ciphertext; a wrong-key participant on a call decodes zero frames. That property is tested, not asserted.
What crypto do you use?
AES-GCM authenticated encryption for media, screen share and message frames. Each room’s key is generated in your browser and shared only through the invite link. MLS-style group key agreement — with forward secrecy and post-compromise re-keying — is on our roadmap; today a room’s key is fixed for the life of that room, so we don’t claim those properties yet.
Where is data hosted?
Our shared cloud runs in the EU (Frankfurt, Germany) — the media SFU reports its eu-central region on every connection. For Switzerland or another jurisdiction, a single-tenant deployment (one app + one database + your SFU) pins hosting where you need it, and you can self-host the whole stack inside your own perimeter.
Do you have certifications?
We’re early and honest about it: the encryption is real and continuously tested end-to-end, but we do not yet hold an external cryptography audit or SOC 2 / ISO 27001. We’re on that path with our first design partners — ask us exactly where we are today.
How does recording stay private?
Recording is explicit and consented — a live badge shows when it’s on. Server-side recording is an opt-in trade-off you control per room.
How do people sign in?
Email & password, magic-link, passkeys (WebAuthn), or social (Google / Microsoft) — and per-organization SSO over OIDC or SAML for teams that bring their own IdP. Two-factor (TOTP) is available on every account. Identity lives in a dedicated service; the media relay stays blind to it.
Verify it yourself
Open a call, share a screen, and watch the SFU relay ciphertext. Seeing beats trusting.