Meetnix

Security & data protection

Written for the person who has to sign it off.

Not a trust badge and not a marketing page with a padlock on it. This is the egress list, the threat model, the hardening, and the paperwork — with the parts that are not finished labelled as not finished.

Report a vulnerability security@meetnix.ai

01 — What leaves

The complete list of outbound connections.

A self-hosted product that quietly phones a telemetry endpoint has lied about the only thing it was selling. So here is every outbound connection a Meetnix deployment makes, and every one of them is either off by default or something you configured.

Destination What is sent Default Can it be switched off?
Your identity provider OIDC discovery, token exchange, JWKS On — it is how sign-in works No. It is the attribution.
Your SMTP relay Invites and digests, if you enabled mail Off Yes
Your ACME provider Certificate issuance for your own domain On if you use ACME Yes — bring your own PEM
A summary model provider The text of a transcript. Never audio, never video. Off Yes — or point it at a model on your own hardware
Us Nothing. There is no telemetry, no licence check, no update ping. — There is nothing to switch off

The audio and video are never in that table. They are written to storage you chose, on a machine you run, and served back through the same sign-in that gates the call — there is no upload step, no hosted bucket and no vendor with a copy.

02 — Threat model

What this design defends against, and what it does not.

Defended

  • A third party holding your recordings. There is no third party. The archive never leaves the machine you put it on.
  • A client lying about who it is. Identity comes from a token your issuer signed. A participant cannot rename themselves into somebody else's transcript.
  • Silent recording. The indicator is derived from the server's own grant, not a flag the client sets. There is no code path that records without every client showing it.
  • Quiet tampering with the record. Per-track hashes in a signed manifest, so an altered file stops verifying.
  • A compromised service reaching the rest of the box. Each unit runs in a systemd sandbox with a deny-by-default address family, a private /tmp, no new privileges and write access to its own state directory only — asserted by a test that boots a real machine.
  • Secrets in an image or a repository. Every secret is a path handed in at runtime. The build refuses to read one from the store.

Not defended — and we would rather say so

  • Your own administrator. Whoever runs the server can read the archive. That is the trade you make by hosting it, and no product that records anything can honestly claim otherwise.
  • A recorded room, from a participant's device. Meetnix records what is said in a room it was granted. If that is not acceptable, the room should be sealed — and then nothing is recorded at all.
  • Somebody pointing a phone at the screen. No conferencing product solves this and the ones that imply they do are selling comfort.
  • A compromised identity provider. If your issuer is signing tokens for an attacker, attribution is exactly as wrong as your directory is. Everything here rests on that signature.
  • Traffic analysis at your edge. An observer who can watch your network can tell that a meeting is happening and roughly how big it is. TLS and SRTP hide the content, not the shape.

03 — Data protection

Self-hosting removes the processor, not the paperwork.

Running Meetnix yourself means there is no processor to appoint, no international transfer to justify and no sub-processor list to keep chasing. You are the controller and the data stays on your estate — which makes the remaining paperwork much shorter, and does not make it zero.

  • Erasure that is real. A deletion request removes that person's tracks and their transcript lines, and records the removal in the manifest — so the archive never quietly pretends they were not there.
  • Data minimisation by default. Video prunes at thirty days; audio, transcript and manifest live as long as your policy says. You are not storing a year of camera feeds because deleting them was somebody's side project.
  • Access is answerable. The audit log covers playback, download, export and search, so "who has seen this recording" is a query rather than an investigation.
  • Purpose limitation you can point at. Meetings are recorded because the room is configured to record. There is no second use, no model trained on the archive, and nothing that can develop one later without you deploying it.
A works council can read the whole system. The recorder is a few hundred lines of Go, the licence permits reading it, and a Betriebsvereinbarung about a system nobody outside the building can read is a very short document. We will sit in that meeting with you. It is usually the fastest part of the evaluation, and the part most vendors cannot do at all.
DPIA templatePre-filled for the standard deployment, with the risk register we would write ourselves.
Works-council packGerman and English, describing what is captured, by whom, for how long, and who can look.
Data mapEvery place a personal identifier is written, including the ones in log lines.
Retention worksheetTurning a legal retention requirement into the policy block that implements it.

Included with Enterprise, and available to anyone self-hosting who asks — hello@meetnix.ai. Withholding compliance paperwork from the free tier would be a strange way to argue that privacy is the point.

04 — Compliance posture

What is certified, what is capable, and what is in progress.

These three are not the same thing and a lot of vendors let them blur. A control you can operate is not a certificate somebody audited, and we will not print a badge for one and let you read it as the other.

Capable GDPR / UK GDPR Self-hosted, you are the controller and there is no processor. Erasure, minimisation, access logging and retention are implemented features, not policies you promise to follow. On Cloud we are a processor under a DPA with EU regional pinning.
Capable HIPAA A self-hosted deployment inside your compliant environment inherits it — there is no third party to sign a BAA with, because there is no third party. On Cloud, we sign one.
In audit SOC 2 Type II For Meetnix Cloud only — a self-hosted deployment is covered by your own controls, not ours. Observation window underway; the report is not issued yet and we will not imply it is. Ask and we will send the current status and the auditor's name.
Planned ISO/IEC 27001 Scoped to the Cloud service, after SOC 2. No certificate today.
Planned Third-party penetration test Annual, with the report published in full rather than summarised into a paragraph. First one commissioned; nothing to show yet.
Shipped Read the source The strongest assurance available, and the one nobody else in this category offers: the recorder, the token minting and the access checks are a few thousand lines and the licence entitles you to read every one of them.

05 — How it is built

The habits, and one bug worth telling you about.

Sandboxed units

Deny-by-default address families, private /tmp, no new privileges, read-only system paths, and a state directory each. A VM test boots a real machine and asserts it, because a sandbox that is only described in a comment is not a sandbox.

Secrets by path

Session key, OIDC client secret and SFU key are files handed in at runtime. Nothing sensitive is read from the store, an image or the repository.

One origin

The browser app and the API it calls share an origin behind the TLS front door; the portal binds to loopback. There is no CORS policy to get wrong because there is no cross-origin request.

Tests that find things

The suite runs under the race detector on every change. Writing it found five real defects, including a payload of null being accepted and filed, and a mail field that carried a header-injection string to the doorstep.

The one we would rather tell you

The SFU webhook path was documented as loopback-only and was, in fact, proxied to the internet by a catch-all rule. The signature check held — it does not depend on where a request came from — but the defence in depth existed only in a comment. Fixed at the edge, and the VM test now asserts both halves.

Reproducible builds

Every artefact is built from a pinned tree with a content hash. What you deploy corresponds to a revision you can check out, and the app will tell a user which one it is running.

06 — Disclosure

Found something? Tell us before you tell anyone else.

Write to security@meetnix.ai. No form, no portal, no bug-bounty platform account to create. If you would like to encrypt it, ask for the key in the first message.

  • Acknowledged inside one working day, by a person.
  • An assessment inside five, with our reading of the severity and whether we agree with yours.
  • Ninety days to a fix and a coordinated advisory, faster if it is being exploited.
  • Credit as you prefer, including none. We will not ask you to sign anything to receive it.
We will never ask a researcher to keep quiet permanently, and we will publish the advisory even when the bug is embarrassing. The webhook one above is on this page for that reason. A security page listing only the things that went right is a security page nobody should believe.

In scope: this website, the Meetnix source, and any instance you run yourself. Out of scope: other people's deployments — do not test a stranger's meeting server, and do not join a meeting you were not invited to in order to prove a point.

Send us your questionnaire.

We will fill it in properly, including the rows where the answer is "not yet". That has never once cost us a deal, and guessing would have.

hello@meetnix.ai See what is not built yet