Security overview

1. What zero-knowledge means here

"Zero-knowledge" is a property of the design, not a slogan. The Quill server is a relay: it moves sealed envelopes between devices and keeps the address label, never the letter.

• The server only ever sees ciphertext. The chat hub accepts an encrypted payload, resolves the recipient, and forwards the same bytes. It has no decryption path, because the keys that would open a message exist only on the sending and receiving devices.
• Delivered messages are not stored. There is no server-side message archive to search, subpoena, or leak. Your history lives in your own app's encrypted database.
• Undelivered messages wait as encrypted blobs. When a recipient is offline, the envelope is held in an offline queue with a hard expiry. The row is deleted as soon as that recipient's device acknowledges delivery, and a background sweep removes anything that expires undelivered.
• Attachments are encrypted before upload. Photos, voice notes and files are encrypted with AES-256-GCM on the sending device; the file key travels inside the end-to-end encrypted message, never alongside the blob. The storage bucket holds bytes the server cannot read.
• Push notifications carry no content. A push payload contains the kind of item (text, image, voice, file, call), the sender's username and, for a group, the group name — never the message.
• Audit logs are metadata. An entry is an event name, the acting user, an IP address, a timestamp and a short detail string (for a relay: the recipient and the ciphertext's size in bytes). No message content is written to a log, anywhere.

2. Encryption

Quill implements the Signal Protocol design — X3DH to establish a session, then the Double Ratchet for every message that follows.

3. Device security

End-to-end encryption moves the risk to the endpoints, so the apps assume the phone or laptop may be picked up by someone else.

• Lock before the app opens. A PIN gate, with biometric unlock where the platform provides it — Android's BiometricPrompt and iOS LocalAuthentication. On Windows the app falls back to the PIN. The PIN itself is stored only on the device, as a PBKDF2-SHA256 hash over 100,000 iterations with a random salt.
• Auto-lock on inactivity. The app re-locks after an idle timeout you control (30 seconds by default), including when it is sent to the background.
• Screenshot and screen-capture blocking. Android uses FLAG_SECURE; iOS covers the window when the app is backgrounded so chats do not appear in the app switcher; Windows uses SetWindowDisplayAffinity with WDA_EXCLUDEFROMCAPTURE.
• Encrypted local database. Messages, attachments and key material live in a SQLCipher-encrypted SQLite file. The database key is derived from a 256-bit random per-device secret held in the platform's secure storage — Android Keystore, iOS Keychain or Windows DPAPI — so a stolen database file cannot be opened from public facts alone.
• Panic PIN. A second PIN that, entered at the lock screen, wipes the local database and sessions and drops the app into an empty state rather than unlocking it.
• Ephemeral and disappearing messages. A conversation can be marked ephemeral so nothing is written to disk at all; individual messages can carry a self-destruct timer, and media can be sent as one-time view.
• Clipboard auto-clear. Text copied out of Quill is cleared from the clipboard after 30 seconds.
• Hidden chats and cover screens. Selected conversations can be hidden behind the app's PIN and revealed only for the current session; a disguise cover screen is available where a workspace allows it.

4. Admin controls

Quill is built for a business that wants a closed roster, not an open network. Your administrator, not us, decides who exists.

• Workspace isolation. Every user and group belongs to exactly one workspace, and the workspace id on the user row — never the username text — is the sole source of isolation. A single server-side chokepoint resolves every client-supplied identifier, and a user in another workspace resolves to "not found". Nothing crosses the boundary: no messages, calls, key lookups, presence, group membership or admin visibility.
• Accounts are created by your administrator. There is no member self-signup. The person who starts the workspace signs up once; after that, accounts are created inside the admin panel, and the server — not the admin — appends the workspace suffix to the username, so an admin cannot mint a name that appears to belong to another workspace.
• Suspend and delete. A suspended account can no longer sign in and gives its seat back. Deletion removes the account and its server-side keys.
• Remote wipe. Wiping a user sends a wipe signal to their registered devices and, on the server, deletes every session, public key, one-time prekey, queued message and push token for that user — so each device is signed out and must re-register from scratch before it can send or receive anything again.
• One-click destroy-all. A platform-level action that deletes users, sessions, public keys, one-time prekeys, the offline queue, groups and membership, device tokens, the IP whitelist and the audit log itself, then purges the uploaded-file store. It is irreversible, it is rate-limited to once per ten minutes, and it is written to the audit log before it runs.
• Audit logs hold metadata only. Authentication, administrative and relay events, each with an actor, an IP, a timestamp and a short detail — never content. Workspace admins see their own workspace's events; platform-level events stay platform-level.
• IP whitelisting and two-factor sign-in. Access can be restricted to a set of source addresses, and TOTP two-factor authentication is supported and can be enforced across a workspace.

5. Infrastructure

The hosted service runs in Amazon Web Services' Mumbai region (ap-south-1), across two availability zones.

• TLS at the load balancer. Public traffic terminates on an application load balancer with a TLS 1.2/1.3 security policy and a certificate for our domain. Everything the apps send — including the already-encrypted message envelopes — travels inside that tunnel.
• Certificate pinning in the apps. The mobile and desktop apps do not simply trust any certificate a device's trust store accepts. Standard hostname and chain validation runs first, then the app checks the presented chain against a pinned set of public-key hashes. A man-in-the-middle with a rogue but "valid" certificate is rejected.
• Rate limiting. Per-IP limits on the HTTP API — 100 requests per minute by default, 10 per minute on authentication endpoints to blunt brute force, one destroy-all per ten minutes — plus per-user limits on the real-time hub so a single authenticated client cannot flood relays, pushes or the offline queue. Repeated failed sign-ins lock the account for 30 minutes.
• Short-lived sessions. Access tokens expire after 15 minutes and are renewed with a refresh token that can be revoked server-side; a remote wipe or a password change invalidates the lot.
• Storage at rest. The database runs with encrypted storage and automated backups; the attachment bucket blocks all public access and has server-side encryption enabled. The attachments inside it are additionally end-to-end encrypted, so the bucket's own encryption is a second layer, not the one that matters.
• No analytics SDKs, no advertising identifiers. The apps contain no third-party analytics, attribution or advertising libraries and read no advertising identifier. The only third-party services in the message path are the platform push services — Firebase Cloud Messaging, Apple Push Notification service and Windows Notification Service — which see an opaque device token and a content-free wake-up payload. (This website uses first-party analytics; the apps do not.)

6. Data residency and India's DPDP Act, 2023

Quill is built and operated from India by Clare Infotech, and the hosted service keeps its data in India.

• Where the data sits. The database, the attachment store and the application servers are in the AWS Mumbai region. Push notifications necessarily leave that boundary — an opaque device token and a content-free payload go to Google, Apple or Microsoft to wake your device — and e-mail for signup and billing notices is sent through a mail provider.
• Data minimisation. There is no phone-number requirement, no contact-list upload, no profile enrichment and no advertising profile. What the server holds is listed in full in our privacy policy, and the list is short because most of what a messenger usually collects simply is not collected.
• Encryption by default. Content is end-to-end encrypted with no setting to turn it off, and the local database on every device is encrypted too.
• Deletion you can actually perform. Your administrator can delete an account, wipe a device, or destroy the entire workspace's server-side data without asking us and without waiting for a ticket.

7. What we cannot do

The same design that protects you removes options from us. These are not policies we could change under pressure; they are consequences of where the keys live.

8. Self-hosted Quill

If "in India, on someone else's servers" is not enough, Enterprise customers run Quill on their own infrastructure.

• The same build. Self-hosted deployments run the same server and admin-panel images as the hosted service, with your own database, storage, TURN server and mail configuration.
• A signed licence, verified offline. The licence is a signed token checked against a public key inside your own deployment. Your server never calls home to validate it, so it works on a network with no route to us at all.
• Self-serve signup off. A private deployment turns signup off entirely; accounts exist only because your administrator created them.
• Then even the metadata is yours. Connection records, audit logs and the offline queue live in your infrastructure. Our access is whatever you choose to grant for support.

Enterprise licensing is arranged directly — write to security@clareinfotech.com.

9. Responsible disclosure

If you have found a vulnerability in Quill, we want to hear about it before anyone else does.

• Where to send it. security@clareinfotech.com. Include what you found, how to reproduce it, and what you think the impact is.
• What we ask. Give us a reasonable window to fix the issue before publishing. Test against your own trial workspace rather than other people's data, and do not run denial-of-service or spam tests against the production service.
• What you get. An acknowledgement that a human has read it, an honest assessment of severity, and credit in the release notes if you would like it. We do not operate a paid bug-bounty programme.