Security at Inboxy

1. Architecture

Inboxy is one service with several ways in: the web app (installable as a progressive web app), desktop apps for macOS and Windows, apps for iPhone and Android, a Slack app and a Telegram bot. All of them talk to the same Inboxy server over HTTPS, and none of them talk to your mail provider on your behalf without going through the server’s checks.

The server keeps two kinds of storage apart:

• A control database that holds identities only — what’s needed to sign you in and find your vault. It doesn’t hold your mail.
• A separate vault per user that holds your mail, credentials, drafts and settings, encrypted under a key that belongs to you alone.

Mail providers are reached with the narrowest access that each feature needs. AI runs where you choose: with a cloud provider (after redaction), on your own computer, or not at all. Our list of the companies that help us run the service is on the sub-processors page.

2. Encryption

At rest

• Message content, triage results (labels, priority, phishing flags), drafts, voice profiles, settings, your profile photo, OAuth tokens and mail passwords are all encrypted at rest.
• We use AES-256-GCM envelope encryption. Each user has their own data key, and that key is itself encrypted (“wrapped”) by a master key that is held outside the database, in a secret manager.
• Every encrypted value is cryptographically bound to its owner and its place — the user, the table and the column — using additional authenticated data. An encrypted value copied into another user’s record, or into a different field, simply fails to decrypt.
• The encryption format is versioned, so we can move to stronger algorithms and rotate keys without a disruptive migration.

In transit

• All traffic between your devices and Inboxy uses HTTPS (TLS).
• Connections from Inboxy to mail and calendar servers use TLS, verified against the server’s hostname.

3. Isolation between users

The worst failure for an email service is one person seeing another’s mail. Inboxy is designed so that this would require breaking several independent layers:

• Separate files. Every user’s data is stored in its own vault file, in a directory named with a keyed hash of the user id and readable only by the service.
• Separate keys. Each vault is encrypted under that user’s own data key.
• No user ids in the API. Request handlers can only reach data through the vault opened from your authenticated session. No API accepts a user id, so there’s no parameter to tamper with. Identifiers that belong to someone else just return “not found”.
• Tested continuously. Automated cross-tenant attack tests replay every route that carries an identifier, as a different user, to confirm nothing leaks.

4. Signing in and sessions

Passwords

Passwords are hashed with scrypt and a unique salt per user; we never store them in readable form. They must be at least 10 characters and are checked against a list of common passwords.

Passkeys

You can sign in with a passkey (WebAuthn) stored on your phone, computer or security key. Passkeys can’t be phished or reused on another site, and we only ever store the public half.

Two-factor authentication and recovery codes

Time-based one-time codes (TOTP) from an authenticator app are available on every account. When you turn them on you get 10 single-use recovery codes — keep them somewhere safe, because they are the way back in if you lose your authenticator.

Lockout and timing protection

• After repeated failures, sign-in is slowed with exponential backoff: per account after 5 failed attempts and per IP address after 30, for up to one hour.
• Unknown email addresses behave exactly like real ones, and authentication responses take a constant amount of time, so attackers can’t tell which accounts exist.

Step-up for sensitive actions

Actions that could hand over your account — such as pairing a new device or deleting your account — need a recent sign-in or a fresh password, two-factor code or passkey.

Sessions and mobile tokens

• Session tokens are random 256-bit values. We store only their SHA-256 hashes, so a copy of our database wouldn’t contain usable sessions.
• On the web, the session is sent in a __Host- cookie marked HttpOnly, Secure and SameSite=Strict, and every state-changing request is checked for cross-site request forgery.
• The mobile apps use a 15-minute access token kept only in memory and a 60-day refresh token kept in the iOS Keychain or Android Keystore. Refresh tokens rotate on every use and work only once; if an old one is ever replayed, that device is signed out.
• Every session is a device you can see, rename and revoke from Settings.

Device pairing

You can add a device by entering a code or scanning a QR code on a device you’re already signed in on. Pairing codes are 40-bit, single-use, valid for 5 minutes and stored only as keyed hashes. Approval is rate-limited, locks after repeated wrong codes and requires step-up. Mail credentials never leave the server — a paired device only receives a session.

Security audit log

Sign-ins, new devices, changes to two-factor settings and other security events are recorded in your audit log. You can review the latest 100 events in Settings.

5. AI safeguards

• Your choice of mode. Use Cloud AI (Anthropic’s Claude, acting as our processor), run AI on your own computer with Ollama so no text goes to an AI provider, or turn AI off. Template drafts still work without AI.
• Redaction first. Before any text goes to the cloud model, we replace email addresses, phone numbers, card numbers (Luhn-checked), IBANs (checksum-verified), social security and other government ID numbers, API keys, JSON Web Tokens, passwords and signed URLs with placeholders such as ⟦EMAIL_1⟧. The real values are put back on our side afterwards.
• No training on your email. Your email content is never used to train AI models — ours or anyone else’s. Anthropic’s commercial terms do not allow it to train on API data. [Confirm retention period with Anthropic’s current terms.]
• Drafts only. AI never sends email. Nothing leaves your mailbox until you press send.
• Prompt-injection limits. The model is instructed never to agree to payments or share credentials and to flag such requests for you instead. Rules and automations run on deterministic triage, never on model output alone, which limits what a malicious email can make the AI do.
• Your voice stays statistics. Drafting “in your voice” uses learned style statistics — greetings, sign-offs, formality — not your raw sent mail as a prompt corpus.

More detail on how AI uses your data is in the Privacy Policy.

6. Safer email

• Tracking pixels blocked. Remote images go through our image proxy, which blocks 1×1 trackers and strips cookies and referrers. Images load only when you ask, so senders can’t tell when you opened their message.
• Sanitised messages. Email HTML is cleaned with DOMPurify and shown in a sandboxed frame with a strict content security policy, so scripts in an email can’t run.
• Phishing detection. We flag display names that impersonate well-known brands, SPF, DKIM and DMARC failures, Reply-To addresses that point to a personal mailbox, and pressure language. Flagged messages go to Suspicious with a plain-language reason.
• Safe unsubscribe. Only https: and mailto: unsubscribe methods are accepted, and RFC 8058 one-click unsubscribe is preferred, so we never “visit” a link that might confirm your address to a spammer.
• Hardened inputs. Custom rule patterns are length-capped and screened for catastrophic backtracking; uploaded profile photos are checked by file signature and size, and only images are accepted.
• Server-side request forgery protection. Every outbound request built from your input or from email content — the image proxy, unsubscribe links, account autodiscovery, CalDAV addresses and custom IMAP/SMTP hosts — is checked before it is made. Each redirect is re-checked. For mail servers, the hostname is resolved, every address must be public and the port must be a mail port; we then connect to that exact address while verifying TLS against the hostname, leaving no window for DNS-rebinding tricks.

7. Connections and integrations

• Gmail and Outlook connect with OAuth 2.0 and PKCE, asking only for the permissions the features need. We never see those passwords. Refresh tokens are encrypted, and if you revoke access, Inboxy notices and asks you to reconnect. How we handle Google data is described in the Privacy Policy.
• iCloud, Yahoo, Fastmail and other IMAP/SMTP providers connect with app passwords, which are encrypted in your vault and never included in exports.
• Proton Mail is end-to-end encrypted, so Inboxy connects through the official Proton Mail Bridge on your computer. We never see your Proton password — only the Bridge password. Connections to private network hosts like the Bridge are blocked on our hosted service by default; running Inboxy on your desktop keeps decrypted mail on your machine.
• Calendars (Google, Microsoft and CalDAV) are read to suggest free time slots.
• Slack and Telegram requests are verified — Slack with signed requests and a timestamp window, Telegram with a secret token. Accounts link through a one-time code, and by default bots receive summaries, never full email bodies.
• Profile photos can optionally be published to Microsoft 365 and Gravatar (through WordPress.com sign-in), only when you ask.

8. Push notifications

• Notifications are delivered by Firebase Cloud Messaging (for Android, iPhone and web push) and, for some Apple devices, directly by Apple Push Notification service.
• Push tokens are stored encrypted in your vault and removed when you sign out or when the token stops working.
• You choose how much a notification shows: none (generic text), the default (sender and a one-line AI summary), or full (subject and snippet). Anything shown passes through the push provider, so pick “none” if that matters to you.

9. Data minimisation and logging

• Sender and sign-in email addresses are never stored in plain text; lookups use keyed hashes.
• Server logs record request paths, times and status codes only — no query strings, message bodies, tokens, cookies, idempotency keys or email addresses.
• We don’t use analytics, advertising or tracking SDKs in any Inboxy app.
• Removing a connected mail account keeps it restorable for 7 days; after that its synced data is purged and, for Google, our access grant is revoked. Accounts are never removed just because of sync or sign-in errors.

10. Backups and key management

• We take encrypted backups every night using AES-256-GCM, with a key derived from the master key. The newest 14 are kept, and copies are stored off-host.
• The master key is stored separately from both the database and the backups, so a stolen backup alone can’t be read.
• Because each user’s data key is wrapped by the master key, we can rotate keys and, when you delete your account, destroy your key without touching anyone else’s data.

11. Export and deletion

• Export. From Settings you can download everything you have as JSON and mbox, streamed as a single archive. It is never written to disk on our servers, the download link is valid for 1 hour, and stored credentials are never included.
• Delete. Go to Settings → Security → Delete Inboxy account (also available on the web). You’ll be asked to confirm who you are. We then destroy your wrapped data key and delete your vault immediately (“crypto-shredding”), which makes all of your encrypted data unreadable at once, and remove your sign-in records. Copies in encrypted backups become unreadable with the key gone, and rotate out within 14 days.

Retention periods are described in full in the Privacy Policy.

12. Operational security

• Least privilege. Access to production systems is limited to the people who need it, using strong authentication. [Confirm process: administrator MFA, access reviews and offboarding.]
• No routine access to content. Our tools are built so that operating the service doesn’t require reading your mail. We access readable data only to provide support you request, investigate abuse or a security incident, or comply with the law.
• Secure development. Changes are reviewed and tested, including automated cross-tenant tests, before release. [Confirm process: code review, dependency scanning and patching cadence.]
• Independent assessment. Because Gmail access uses a restricted Google scope, Inboxy undergoes Google’s OAuth verification and a Cloud Application Security Assessment (CASA). [Confirm assessment tier and date.]
• Incident response. We have a process to contain, investigate and fix security incidents, and to notify affected users, business customers and authorities as the law requires. Business customers receive breach notice under our Data Processing Addendum. [Confirm process: documented incident response plan and on-call.]
• Vendors. We use a small number of sub-processors, each under written data protection terms. The list is on our sub-processors page, and the full set of measures we commit to business customers is in Annex 2 of the Data Processing Addendum.

13. This website

This site (inboxy.nexlla.com) is static. It sets no cookies and loads no analytics, third-party scripts or third-party fonts — even our font is self-hosted. A strict content security policy only allows resources from our own domain. The only thing it stores in your browser is your light or dark theme choice. See our Cookie Policy for details.

14. Reporting a vulnerability

We welcome reports from security researchers and users. If you believe you’ve found a security issue in Inboxy, please email [email protected]. Our contact details and policy are also published in machine-readable form, following RFC 9116, at https://inboxy.nexlla.com/.well-known/security.txt.

What to include

• A description of the issue and its potential impact.
• The affected app, version, URL or endpoint.
• Clear steps to reproduce it, with a proof of concept if you have one.
• Any accounts you used for testing (never send us real passwords).
• How you’d like to be credited, if at all.

Please don’t include other people’s personal data in your report. If you accessed any by accident, tell us and delete it.

What you can expect from us

• An acknowledgement within 3 business days.
• An initial assessment and regular updates while we investigate and fix the issue.
• A note when the issue is resolved and, with your permission, credit for your report.

Scope

In scope: the Inboxy service at inboxy.nexlla.com, including the web app and its API; the Inboxy desktop apps for macOS and Windows; the Inboxy apps for iPhone and Android; the Inboxy Slack app and Telegram bot.

Out of scope:

• Services we don’t run, including Google, Microsoft, Apple, Proton, Yahoo, Fastmail, Slack, Telegram, Anthropic and our hosting provider — please report to them directly.
• Denial-of-service, load or stress testing, and spam.
• Social engineering or phishing of our staff or users, and physical attacks.
• Findings from automated scanners without a demonstrated impact.
• Missing best-practice headers or settings without a demonstrated security impact, clickjacking on pages with no sensitive actions, and self-XSS.
• Issues that require a compromised device, a rooted or jailbroken phone, or outdated, unsupported browsers.
• Rate-limiting or brute-force reports that don’t bypass our lockout controls.

Rules for testing

• Only test against accounts you own, or have the account holder’s explicit permission to use.
• Don’t access, change or delete data that isn’t yours, and stop as soon as you’ve shown the issue exists.
• Don’t degrade or disrupt the service for others.
• Don’t use a vulnerability beyond what is needed to demonstrate it, and don’t keep any data you obtain.
• Keep the issue confidential until we’ve fixed it, and give us reasonable time — normally [90 days] — before any public disclosure. We’ll agree a date with you.
• Comply with all applicable laws.

Safe harbor

If you make a good-faith effort to follow this policy, we will consider your research authorised, we will not pursue or support legal action against you for it, and if a third party brings a claim against you over activity that complied with this policy, we will make it known that your actions were authorised by us. This commitment applies only to us and to the extent that we are able to give it; it cannot bind public authorities or third parties. If you are unsure whether something is allowed, ask us at [email protected] before going further. [Counsel to confirm safe-harbor wording under UAE law, including Federal Decree-Law No. 34 of 2021 on Combatting Rumours and Cybercrimes.]

Rewards

We don’t currently run a paid bug bounty programme, so we can’t offer payment for reports. We are genuinely grateful for responsible disclosure and are happy to credit researchers who wish to be named.

15. Contact

• Security issues and vulnerability reports: [email protected]
• Privacy questions and data requests: [email protected] — see also the Privacy Policy
• Help with your account: [email protected]

Inboxy is operated by [Nexlla Creative Agency — registered legal name], trading as Nexlla Creative Agency, [Registered address — street, building, city, Emirate, United Arab Emirates].

Questions about security at Inboxy? Write to [email protected].