Trust
How we protect your meetings
A plain-language account of how Si-Des Meet protects meetings: what is encrypted and where, who can see what, what we store, and where the limits are. We say “designed to” when a property depends on correct use, and we list what we have not done.
End-to-end encryption
Meetings can be encrypted so that only participants’ devices can read audio, video and in-meeting messages. The key lives only in the invite link’s # fragment, which browsers never send to a server.
Device trust and enforced moderation
A hashed device identifier backs per-device rate limits, device bans and a short badge that helps expose impersonators. Removing someone is carried out by the server, not left to their browser.
Encrypted media
Audio and video travel over WebRTC with DTLS-SRTP encryption between your device and the LiveKit media servers. Media does not pass through our web server and is not stored unless the host starts a local recording.
Single sign-on, no passwords here
Sign-in is handled by Si-des Auth over OpenID Connect. Si-Des Meet never sees or stores your password; roles come from the signed session and are checked on the server.
Scoped passcodes
Hosts can require a passcode per meeting. Attempts are throttled to stop brute-force guessing, and after several wrong tries the person is asked to wait before trying again.
Waiting room and host controls
Guests can wait until the host admits them. Hosts and co-hosts can admit or deny people, moderate the room and end the meeting. Host status is decided by an atomic server-side claim, not by who clicks first.
Geofencing enforced server-side
Restrict who can join by country, device type, browser or operating system. The rule is checked when the join token is issued, so hiding a button in the interface cannot bypass it.
Rate limiting
Sensitive endpoints — passcode attempts, the contact form and AI assistant dispatch — are rate limited per client or per room, which slows down abuse and automated scripts.
Short-lived, signed tokens
Room access uses signed, short-lived LiveKit tokens. Server routes that use the LiveKit admin key verify the caller’s room-admin token first, and secrets stay in server environment variables — never in the browser.
Data minimisation
No media is stored on our servers. Chat and Q&A live only in your browser during the meeting and are cleared when you leave. Recording, when enabled, happens locally in the host’s browser. The edge layer also sets hardening headers such as CSP and HSTS.
Threat model summary
What we design against, and what can still go wrong. This is a summary, not a full formal model.
| Threat | How we address it | What remains |
|---|---|---|
| Eavesdropping on the network | TLS for the website and signalling, DTLS-SRTP for media, HSTS so browsers insist on HTTPS. | Traffic metadata (who connects, when, how much data). |
| A curious or compromised server or media provider | In end-to-end encrypted meetings the server only ever holds ciphertext, and the key never reaches it. | In standard meetings the media server can process media. AI-assisted meetings are standard by design. |
| Uninvited people joining | Passcodes compared in constant time with rate limiting, waiting room, geofencing, and short-lived signed room tokens. | Anyone holding the link and passcode. An encrypted invite link is a secret: whoever has it can join. |
| A disruptive participant | Only hosts and co-hosts can remove, mute everyone, record or promote, and the server checks the sender. Removal happens at the media server, with optional device bans and in-room reporting. | A determined person can switch browser or device to get around a device ban. |
| Impersonation | A short device badge next to each participant, and safety codes so people can detect a swapped key. | Guests choose their own display names. Safety codes only help if people actually compare them. |
Out of scope
What is encrypted where
| Data | Standard meeting | End-to-end encrypted meeting |
|---|---|---|
| Audio, video, screen share | Encrypted in transit (DTLS-SRTP) between each device and the media server, which can process it. | Encrypted per frame on your device (AES-GCM). The media server sees only ciphertext. |
| Chat, polls, Q&A, whiteboard, reactions | Sent over encrypted WebRTC data channels; the media server can read them. Kept in browsers, not in our database. | Encrypted with the meeting key before sending. Kept only in browsers. |
| Signalling and API calls | Protected by TLS (HTTPS and WSS). | The same. Signalling is needed for routing, so it is not end-to-end encrypted. |
| Stored account and meeting data | In our database (see “Data we store”). Encryption at rest depends on the database provider you use. | The same. The meeting key is never stored. |
| Recordings | Started by the host and made in the host’s browser, saved on their device. We do not upload them. | Server-side recording and streaming are not available. |
| AI assistant | Audio and messages sent to it are processed by the AI providers set up by the administrator. | Not available. |
| Live translation | On your device when the browser supports it; otherwise sent to our server and translated by an AI model. | On your device only, unless you opt in to server translation. |
End-to-end encryption flow
The host’s browser creates a 256-bit key and puts it in the invite link’s # fragment. LiveKit then encrypts every media frame and every data packet with keys derived locally from it (SFrame-style per-frame AES-GCM, key derivation by PBKDF2 inside the SDK). We use the encryption built into the open-source LiveKit SDK rather than our own cryptography. A safety code, a SHA-256 fingerprint of the key shown as five groups of four characters, lets participants confirm out loud that they hold the same key.
How to use it, step by step →Device trust
The browser computes an anonymous visitor identifier with the open-source FingerprintJS library. Our server immediately turns it into an HMAC hash using a secret key. The raw identifier is never stored, compared or shown.
- Per-device rate limits slow automated abuse even when someone changes IP address.
- When a host removes a participant, the server disconnects them through LiveKit’s RoomService API. The host can also ban that device from re-entering the room (24 hours by default).
- A short badge (for example 7K2Q-9MXA) appears next to participants. The same badge means the same device. A different badge under a familiar name may be an impersonator.
Server hardening
- Browser protections — A strict Content-Security-Policy, HSTS with preload, a Permissions-Policy that switches off features we do not use, frame protection against clickjacking, no-sniff and referrer controls, and no X-Powered-By header.
- Input and abuse limits — Inputs are validated on the server. Every API is rate limited per client, with tighter limits on tokens, passcodes, the contact form and reports.
- Signed, short-lived proofs — Host status, waiting-room admission and phone-camera access are signed proofs with short lifetimes. Room tokens are pinned to a single canonical room, so a token for one meeting cannot be reused for another.
- Authorised moderation — Messages that remove people, mute everyone, start recording or promote a co-host are only honoured when they come from a host or co-host. Moderation API routes verify a room-admin token on the server.
- Secrets and sign-in — Passwords are handled by Si-des Auth over OpenID Connect with PKCE; Si-Des Meet never sees them. Server secrets stay in environment variables and are never sent to the browser.
Data we store
This list follows our database schema and code. Retention periods are given where the system enforces one; where it does not, we say so.
| What | Where | How long |
|---|---|---|
| Account: name, email, role, preferences, notifications | Our database | Until you ask us to delete it or an admin removes it. |
| Meetings: title, description, times, settings, invitee emails and passcode | Our database | Until the host or an admin deletes the meeting. Passcodes are stored as entered so hosts can see and share them; they are compared in constant time and rate limited. Use a passcode you do not use elsewhere. |
| Room records: waiting-room choice and who claimed host | Our database | Kept with the room record. No automatic expiry is set today. |
| Device bans: room, hashed device identifier, expiry | Our database | Ignored after they expire (24 hours by default). |
| Conduct reports: category, details, evidence, who reported whom, status | Our database | Kept for moderation records until an admin removes them. No automatic deletion today. |
| Role-play practice sessions: transcript, scores and feedback | Our database | Kept with the owner’s account until deleted. |
| Chat, Q&A, polls and whiteboard content | Your browser or server memory | Only in participants’ browsers. Cleared when you leave, when the meeting ends or when you close the tab. |
| End-to-end encryption key | Your browser or server memory | In the invite link’s # fragment and the tab’s session storage. Removed from the address bar after loading. Never sent to any server. |
| Rate-limit counters | Your browser or server memory | In server memory for minutes. Not written to the database. |
| Contact-form messages | Email inbox (not our database) | Sent by email to our support inbox. Not stored in the database. Kept in that mailbox until deleted. |
Our hosting, database, media and email providers keep their own operational logs under their own policies.
Privacy policy →Independent assurance
Si-Des Meet has not been independently audited and does not hold SOC 2, ISO 27001, HIPAA or similar certifications. We do not claim any. We publish how the system works so you can assess it against your own requirements.
If you handle regulated data, check with your compliance team before use and consider self-hosting so that you control the infrastructure.
Found a vulnerability?
Please tell us privately before sharing a vulnerability publicly. Include the affected page or API, steps to reproduce and the impact you see. Put “Security report” in the subject. Use the contact form or the email address on the contact page; we read every report, acknowledge it and fix confirmed issues as quickly as we can.
Please act in good faith: do not access other people’s meetings or data, do not degrade the service for others and do not publish details before a fix is available.