Security at Spotrum

Spotrum is built around one promise: a conversation should produce a result you can trust — and nobody, including us, should see more of it than you chose to share. This page explains how that works in practice, in plain language. For how we handle personal data generally, see our Privacy Policy.

1. Encryption in every room

All traffic between your device and Spotrum is encrypted in transit: media over DTLS-SRTP, signalling and API calls over TLS. Recordings, transcripts, summaries and files are encrypted at rest on our servers. This is the baseline for every room, on every plan.

2. End-to-end encryption (E2EE)

Any private room can additionally be end-to-end encrypted — included on every plan, chosen when the room is created and immutable afterwards. In an E2EE room the encryption keys exist only on participants’ devices:

• Each participant generates an ephemeral ECDH P-256 key pair on their device. Private keys are non-extractable — they cannot be exported, even by our own code.
• A random 256-bit room key (AES-GCM) is generated client-side and delivered to each participant individually, wrapped with a pairwise key derived via ECDH. Our servers relay only opaque ciphertext — they never see the room key.
• When a participant leaves, the room is re-keyed with a new epoch, so a former member cannot decrypt anything said after they left (forward secrecy).
• Participants can compare a safety number (a SHA-256 digest of all public keys, shown as 15 digits) out of band to rule out man-in-the-middle attacks.

Voice and chat message bodies in E2EE rooms are encrypted with this room key (AES-GCM, per-message random IV). Metadata required to route messages — room id, sender identity, timestamps — is not end-to-end encrypted.

3. What E2EE means for recording and AI

E2EE rooms cannot be server-recorded, transcribed or summarised — by design. Features that need access to the audio simply do not exist there: our servers only ever see ciphertext, so there is nothing they could record or send to an AI model. This is not just a hidden button — the server rejects recording requests for E2EE rooms and the AI assistant is disabled in them, regardless of what a client asks for. The same constraint applies to our staff and to moderation tooling: there is no administrative mode that can listen to an E2EE room.

If you need recording, speaker-attributed transcripts and AI reports, use a standard room. It is still encrypted in transit and at rest; the difference is that our infrastructure can process the audio server-side to deliver those features — auto-transcription and auto-summary stay off by default and are enabled per room by the host.

4. Verifiable reports

Exported PDF reports carry a QR code with a signed link. The signature is an HMAC-SHA256 over the report ID and issue time, computed with a server-held secret. The verify page confirms that the report was genuinely issued by Spotrum for that recording at that time, and shows only metadata — never transcript content. Verification of the PDF’s byte-level content (document hash embedding) is on our roadmap; until then we deliberately word the guarantee as “issued by Spotrum”, not “bytes unchanged”.

5. Keys and secrets

• E2EE room keys live only on participants’ devices (non-extractable keys in browser storage); they are never transmitted to or stored on our servers in any readable form.
• Report-signing secrets are server-side only and fail closed: if the signing secret is not configured, the service refuses to sign or verify rather than falling back to a weak default.
• Passwords are stored as salted hashes; session tokens are short-lived JWTs.

6. Hosted in Europe

Spotrum is operated by COUBUS OÜ, a company in the European Union, and every server we run is self-hosted in an EU data centre — the API and web app, media servers and TURN relays, databases, file storage, the recording archive and mail. Your account data, room files, recordings and transcripts are stored on those EU servers, under EU jurisdiction, with the GDPR as our home legal framework rather than an export requirement. Business customers sign their DPA with an EU data controller.

Some optional features rely on named providers outside the EU (see section 7) — AI features, maps, app-store billing, third-party sign-in and push notifications. Those transfers are covered by Standard Contractual Clauses. AI transcription and summaries are off by default and enabled per room, and E2EE rooms never send content to AI.

7. Sub-processors

We use a small set of sub-processors, each only for what it is named for:

• Groq, Inc. (USA) — AI transcription, summaries, translation, the in-room AI assistant and this site’s assistant. Transcription and summaries run only in standard rooms where the host enabled them; inputs are not retained beyond short-window operational logging.
• Mapbox (USA) — maps and geocoding in the web and Android apps.
• Stripe — card payments and subscriptions on the web.
• Google — push notifications (Firebase Cloud Messaging), Google Play billing and Google sign-in.
• Apple — Sign in with Apple, App Store billing and push notifications.

Transfers outside the EU rely on Standard Contractual Clauses. The authoritative, always-current list with roles lives in our Privacy Policy. E2EE room content is never sent to any sub-processor — see section 3.

8. Retention and deletion

Recordings, transcripts and reports are retained per your plan (up to 365 days on paid tiers) and can be deleted by the host at any time. Deleted rooms move to a recoverable “Recently deleted” state and can also be purged immediately (“Delete now”). When you delete your account, associated personal data is deleted or anonymised as described in the Privacy Policy.

9. Platform hardening

Rate limiting and abuse controls on authentication and messaging, intrusion monitoring with automated banning, security headers and a Content-Security-Policy rollout, dependency and patch management, and continuous infrastructure monitoring. We run recurring internal security reviews — the most recent full audit (June 2026) remediated all critical and high findings before this page was published.

10. Incident response

If we become aware of a personal-data breach, we assess impact, contain it, and notify the supervisory authority and affected users where required by GDPR (Articles 33–34) — without undue delay. Suspected abuse or account compromise: contact security@spotrum.com immediately.

11. Responsible disclosure

We welcome good-faith security research. Report vulnerabilities to security@spotrum.com with reproduction steps; we will acknowledge, keep you informed, and not pursue legal action for research conducted in good faith (no data exfiltration, no service disruption, no access to other users’ data).

12. Data-processing agreement (DPA)

Business customers who need a DPA (GDPR Article 28) can request one at legal@spotrum.com. Operator: COUBUS OÜ (registry code 14419079), Vesivärava tn 50-301, 10152 Tallinn, Estonia.