Security
This page exists in French and in English. The French version is the authoritative one.
1. What this page is, and is not
This page describes how Quavern's services are built and operated, in enough detail to be checked against them. It is written for the person who has to decide whether to put an organisation's work on a service run by a small studio.
It is not a certificate. Quavern holds no ISO 27001 certification and no SOC 2 report, and nothing here should be read as implying one. Where this page and the privacy policy disagree, the privacy policy prevails: it is the legal document, and it carries the authoritative list of sub-processors and retention periods.
2. Where the data is held
The applications and their databases run on one set of servers inside the European Union, hosted on Microsoft Azure (Microsoft Ireland Operations Limited). Requests reach them through Fastly, which serves every Quavern website and API.
Other companies process parts of the service on Quavern's behalf: payments, e-mail delivery, text messages, support conversations, error reporting, the status page, the open-source index and the model that answers in Marl. Each is named in the privacy policy, with what it receives and why. That list is kept current there rather than repeated here, so there is one version of it.
Databases and their backups are encrypted at rest by the platform, and traffic between you and Quavern is encrypted in transit.
3. Signing in
Passwords are stored as Argon2id hashes. They are never stored in a form anyone can read, Quavern included, which is also why a forgotten password is reset rather than retrieved.
A second step can be added to any account, and more than one at once: an authenticator application, a passkey held by your device or security key, or a verified telephone number as a fallback code. A passkey or an authenticator application is the stronger choice; the telephone is there for the account that would otherwise have nothing.
A signed-in session is a short-lived access token with a refresh token that rotates when it is used. Every device holding a credential is listed in your account and can be revoked there, one by one; changing your password ends the other sessions.
4. Keys and tokens
API keys are shown once, at creation, and stored only as a hash. A lost key is replaced, not recovered. Any key can be revoked from the account, and revocation takes effect on the next request.
Every credential carries an audience, a set of scopes and an owner. A token issued for one Quavern client is refused by another, a token scoped to reading cannot write, and an organisation's service token can be revoked by its administrators without touching anyone's personal access. Each plan has its own rate limits and usage budget, enforced on every request.
5. Who at Quavern can see what
No customer account can hold staff privilege. There is no administrator flag on a customer record: staff are a separate kind of record entirely, so a mistaken migration or a support tool with one wrong condition cannot turn a customer into an operator.
Operators work in a separate console, on its own address, which is not reachable with a customer account. Signing in to it requires a Quavern work account in Google Workspace with two-step verification enforced, from a device enrolled by Quavern; an account suspended centrally is an operator who cannot sign in, with no second place to revoke.
Every action in that console records who performed it, when, on what, and the reason they typed — including actions that only read a record. Those entries cannot be edited or deleted. If you ask why something happened to your account, the answer comes from that log rather than from memory.
Support conversations are handled in a separate tool. The console does not read the content of Marl conversations.
6. The network and the applications
Everything is served over HTTPS with HSTS; there is no unencrypted path to any Quavern service. Each application sends a content security policy, and the browser surfaces carry no advertising, marketing or audience-measurement tracker at all.
The applications are isolated from one another on the host, each running as its own unprivileged service with its own limits. A request that presents itself as coming from the content delivery network has to carry a secret only that network holds, so the visitor address a request is attributed to cannot be forged by pointing another service at the servers.
Automated abuse is met with a graduated response rather than one blunt rule: a suspect sign-up is asked to prove it is a person before it is refused, and a block is recorded with its reason and its author.
Dependencies are pinned, and each release is built and tested before it is deployed, with the previous version kept for an immediate rollback.
7. Taking your data back, and deleting it
Your account holds an export of what each service knows about you, and a deletion for each service that has its own data — the Marl conversations and attachments, the Quavsit usage, boards, widgets and feed watches. Deleting a service's data revokes that service's keys with it, and the deletion is immediate rather than queued.
Closing the account removes the identity and everything attached to it, except records Quavern must keep — invoices, chiefly — for the period the law sets. Retention periods are listed, service by service, in the privacy policy.
8. Reporting a vulnerability
Write to hello@quavern.com, with the word Security in the subject line. Describe what you found, where, and the smallest sequence that shows it. A human answers within three working days, and you are told what was done and when it was fixed.
There is no bug bounty; Quavern is a small studio and will not pretend otherwise. Credit is offered publicly to anyone who wants it.
Safe harbour. Research carried out in good faith and within the rules below is welcome: Quavern will not pursue legal action over it, and will not report it to the authorities. The rules are the usual ones, and they exist to protect other people rather than Quavern:
- use only accounts and data that are yours;
- stop as soon as you can demonstrate the problem — do not read, copy, alter or keep anyone else's data;
- no denial of service, no load testing, no spam, and no attempt to degrade the service for others;
- no social engineering of people, and no physical intrusion;
- give Quavern a reasonable chance to fix it before telling anyone else.
The same address is published in machine-readable form: /.well-known/security.txt
9. What is not claimed
Quavern is a small studio, and the honest description of its scale matters more than a reassuring one:
- no security certification, and no audit report to send;
- no availability commitment outside a signed contract — the public status page records what actually happened, including the incidents;
- the services run from one region, which means a regional failure is an outage rather than a failover;
- penetration testing is not commissioned on a schedule.
Where a control does not exist, this page says so rather than describing an intention.
10. Agreements and documents
A data processing agreement under article 28 of the GDPR is available for organisations that need one: write to hello@quavern.com and it is sent for signature. Ask in the same message for anything else a review needs — the sub-processor list, the retention table, the hosting region.
The documents already published: