Privacy
Privacy Policy
What Railgun stores about you, what it cannot see, and what it hands to the providers it relies on — per product, as the software works today.
Last updated
Overview
Railgun is built to collect as little as it can. That principle is honoured in what we store about you: no phone number, no contact upload, no advertising profile. It is only partly honoured in message content today. Direct messages are encrypted on the client only on the paths that reach our sealed-box code — the browser and development builds. On the Electron desktop build the handler that should encrypt them base64-encodes instead, so we receive them readable. Community and channel messages are not encrypted on any client. We would rather say so here than let the word “encrypted” do work it has not earned.
What the server can and cannot read
| Content | Today |
|---|---|
| Direct messages — browser & development builds | Encrypted on the client with libsodium sealed boxes. The relay receives ciphertext it cannot open. |
| Direct messages — Electron desktop build | Not encrypted. When the native libsignal module loads, the client routes encryption through an IPC handler that base64-encodes the message instead of encrypting it, so the relay receives readable text. See the encryption reference. |
| Community & channel messages | Not encrypted. Channel encryption is written but not wired into any shipping client, so the server receives readable content. |
| Railgun-to-Railgun and outbound mail | Not encrypted at rest. Internal and outbound messages are stored as they were submitted, so anyone with the database can read them. Only inbound external mail goes through the at-rest encryption described in the next row. |
| Mail from outside Railgun | Arrives as plaintext SMTP and is parsed on the server — unavoidable when the sender is Gmail — then encrypted at rest with AES-256-GCM under a key the server holds. We can technically decrypt it; an attacker with the database alone cannot. |
| Private keys | Never transmitted. No code path sends private or identity key material to the server. |
What We Don't Collect
- Phone numbers — not required to register
- Your address book or contact list — nothing is uploaded
- Private or identity key material
- Advertising or cross-site tracking identifiers. The website analytics described below run with Google Signals and ad personalisation switched off, so the identifier they set is first-party and is not used to build an advertising audience or to follow you onto other sites
What We May Collect
- Account identifiers (username, device IDs)
- Community, channel, group, and membership records needed to operate the service
- Community and channel message content, for as long as it remains unencrypted
- Direct-message content from clients whose encryption path is not the sealed-box one — today, the Electron desktop build
- Encrypted envelopes and routing metadata for delivery
- Authentication events — sign-in, sign-out, and session changes are written to an audit log
- Mail stored in your @railgun.chat mailbox. Inbound external mail is encrypted at rest under a server-held key; internal Railgun-to-Railgun mail and mail you send are stored as submitted
- Open and click events for outbound mail you choose to send with tracking enabled
- IP addresses (temporarily, for rate limiting)
- Billing and entitlement references for paid products
- Crash reports (opt-in, anonymized)
- Website analytics on our public marketing pages, only if you agree to them — see Cookies and website analytics below
Cookies and Website Analytics
This section is about this website. It is not about the Railgun apps, the browser extension, or your mail — none of which contain analytics of any kind.
Our public marketing pages use Google Analytics to tell us which pages bring people to Railgun. It loads only after you accept it, and only on public pages. It is never loaded on any signed-in surface, on the admin console, or on sign-in, registration, recovery, invite or unsubscribe links — those URLs often identify one person, and they are never reported. If you decline, or simply ignore the banner, no request is made to Google at all.
Where it does run, it is configured with IP anonymisation on, and with Google Signals, ad personalisation and advertising storage switched off. We use it to count visits to pages, not to build a profile of you.
Cookies this site sets on its own, without asking, are limited to the ones needed to work: your language choice, and — if you sign in — your session. Declining analytics also deletes any analytics cookies already stored in your browser.
You can change your mind at any time by clearing this site's data in your browser, which removes the stored choice and the banner will ask again.
Encryption
Where a direct message is encrypted, it is encrypted in the client using libsodium sealed boxes — X25519 key agreement with XSalsa20-Poly1305 authenticated encryption. Sealed boxes protect content in transit and at rest on the relay, but they do not provide forward secrecy: a recipient private key that leaks later can open messages captured earlier. That path is selected only when the native libsignal module is absent, which today means the browser and development builds. On the Electron desktop build libsignal loads, and the direct-message handler it selects base64-encodes rather than encrypts.
A full Signal-style implementation — X3DH key agreement and the Double Ratchet — exists in the codebase but is not instantiated by any shipping client. Until it is, no Railgun release provides ratcheting forward secrecy, and this policy will not claim otherwise. Community and channel messages are not encrypted at all yet. Private key material stays on the device; public pre-key bundles are stored by the service so that others can start a conversation with you.
Data Retention
Messages are relayed, not archived. An envelope for an offline device is queued in Redis with a 30-day maximum TTL and deleted once the device acknowledges it. There is no server-side message history: your conversation history lives in local storage on your own devices, and losing the device loses the history.
Mail is the exception. Messages in your @railgun.chat mailbox are stored in the database until you delete them — inbound external mail encrypted at rest, internal and outbound mail as submitted. Account and membership data is retained while an account remains active or as legally required.
Billing
Paid plans are billed through Stripe, which collects your card and your email; we never see the card. On our side we store a reference to your Stripe customer, your tier and your renewal dates, in the same database as your account — so today those records and your username can be joined. We intend to separate them. How billing privacy works today, and where it is going.
Your Rights
The in-app account-deletion workflow is temporarily unavailable because deletion across every dependent data store is not yet safely implemented. It now fails without deleting partial data. To submit a privacy or deletion request, contact the address below while this is remediated.
Contact
For privacy-related questions, please contact us at privacy@railgun.chat