Legal

Security

Last updated: August 21, 2026

Dumpling holds your notes, your calendar, and the names of people you know. This page describes how that data is protected, what Dumpling deliberately isn't, and how to report a problem.

Accounts and sign-in

Passwords are hashed with Argon2, the current recommended password-hashing function, and stored only in that form. No one can ever read your password.

Signing in gives your device a short-lived access token and a refresh token. Refresh tokens are stored hashed, rotate every time they're used, and can be revoked. Changing your password or deleting your account revokes every session everywhere. On your device, tokens live in the operating system's secure storage (Keychain, Credential Manager, or Keystore), not in a plain file.

Keeping accounts apart

User data is isolated with PostgreSQL row-level security, enforced at the database layer rather than trusted to application code. The role the application connects as cannot bypass it, so a query that forgets its user filter returns nothing rather than someone else's notes.

In transit and at rest

All traffic between your device and our servers is encrypted with TLS, with certificates renewed automatically.

At rest, your data sits in an ordinary PostgreSQL database on disks we control, protected by access control rather than per-record encryption. This is the trade-off that makes search, the knowledge graph, and the AI assistant possible. See What we don't do for what that means for you.

Backups

The database is backed up daily. Backups are encrypted before they leave the server and stored off-site with a provider that holds no key and cannot read them. Snapshots are retained for up to roughly six months.

Access and monitoring

Production access is restricted, used only for operating the service (deploys, migrations, investigating a fault) and logged. Nobody browses your notes, and there's no internal tool for doing so.

The API is rate limited per user and per endpoint, abusive traffic is blocked automatically, and audit logs of security-relevant events are kept for 90 days.

Our service providers are listed on the service providers page, each contractually limited to processing on our instructions.

What we don't do, stated plainly

• Dumpling is not end-to-end encrypted. We hold the data in a form our servers can read. That's what makes search, auto-connections, and the AI assistant work. If your threat model requires that no provider can technically read your data, Dumpling is the wrong tool and we'd rather say so here than let you find out later.
• No SOC 2, ISO 27001, or HIPAA compliance. Those are real programmes with real audits, and claiming them without one would be a lie. Dumpling is not built for protected health information or regulated data.
• No bug bounty. We can't pay for reports yet, but we'll credit you if you'd like.

Reporting a vulnerability

If you've found a security issue, please tell us at support@getdumpling.app with "Security" in the subject. Include what you found, how to reproduce it, and what an attacker could do with it. We'll acknowledge within 3 business days and keep you updated until it's fixed.

Our commitment to you: if you report in good faith, follow the rules below, and give us reasonable time to fix the issue, we won't pursue legal action against you and we'll credit you publicly if you'd like.

The rules, which exist to protect other users rather than to trip you up:

• Test only against your own account. Don't access, modify, or retain another user's data. If you stumble into it, stop and tell us.
• No denial of service, spam, social engineering, or physical attacks.
• Don't run automated scanners against production.
• Give us a reasonable window to fix it before publishing, and tell us when you plan to.

If something goes wrong

If a breach affects your data, we'll notify you and the relevant regulators within the timeframes the law requires: 72 hours to a supervisory authority under the GDPR, and without unreasonable delay to you. The notice will say what happened, what data was involved, what we've done about it, and what you should do. We would rather publish an uncomfortable postmortem than a vague one.