Security
An unpublished manuscript is not ordinary data. This page says what protects yours, in enough detail to check, and what does not.
Accounts
- Passwords hashed with Argon2
- Sign-in token expires after 15 minutes
- Refresh cookie is httpOnly, Secure and SameSite=strict, scoped to the auth path
- Sign-in is rate limited per address and per IP
Isolation
- Every query filters on the owning account, in the query itself
- Another writer's book answers 404, never 403, so its existence is not confirmed
- A test asserts this across books, chapters and paragraphs
In transit
- TLS everywhere, with HSTS for a year
- Strict Content-Security-Policy
- Framing denied, MIME sniffing off, referrers trimmed
- The microphone is the only device permission requested
The machine
- A server in Sweden, not shared with other customers
- The database and job queue are not reachable from the internet
- The API is reachable only through the web server on the same host
Isolation, a little deeper
Qlemi is multi-tenant: several writers share one service and never share data. The rule is that ownership is part of the query rather than a check bolted on after it, so a request for a book you do not own returns nothing to filter. It answers 404 rather than 403 on purpose: a 403 would confirm the book exists.
The test suite asserts this rather than trusting it. Every endpoint carries a cross-account test alongside its happy path, and test_cross_user_access_is_404 walks a second account through another writer's book, chapters and paragraphs and requires 404 from every one. 279 backend tests and 50 browser test files run before anything reaches production.
Where your manuscript lives
In a Postgres database on a server in Sweden that I run. Generated audio sits on a disk volume on the same machine. Nothing is stored with a third party.
Reading aloud and dictation do send text and audio to OpenAI, and some features send text to Anthropic. That is a privacy question more than a security one, and it is set out feature by feature on the privacy page.
Backups
Described exactly as they are, because a vague answer here is worth nothing.
- The database is dumped every night.
- 30 days of dumps are kept on the server, and a year on a second machine.
- The dump is verified to restore: it has been restored into a throwaway database and the row counts checked against production.
- The dump is written to a temporary file and only becomes the newest backup once it is complete, so a truncated dump never masquerades as a good one.
What backups do not cover. There is no point-in-time recovery, so in the worst case up to a day of writing could be lost. Both copies are in the same building, so a fire would take both. A third copy elsewhere is planned and not done.
What Qlemi does not have
Qlemi is built by one person and is in active development. It is careful where it counts and it is not going to claim more than that.
- No external security audit and no penetration test.
- No certification. No SOC 2, no ISO 27001.
- No on-call rotation. If it breaks at three in the morning it is fixed when I wake up.
- No account deletion button yet. Email and it is done by hand, which is the honest position until it is built.
If any of those are requirements for your manuscript, they are requirements Qlemi does not meet today.
Found a problem?
Email [email protected]. Describe it, ideally with the steps to reproduce, and leave other people's data alone while you look. Reporting something in good faith will never be held against you, and you will get an answer.