Legal

Security

Last updated: August 20, 2026

Dumpling holds your notes, your calendar, and the names of people you know. This page describes how that's protected, what it deliberately isn't, and how to tell us if you find a hole. No certifications to wave around — Dumpling is a small independent product, and the honest thing is to show the engineering rather than a badge.

Accounts and sign-in

Passwords are hashed with Argon2, the current recommended password-hashing function, and stored only in that form. We can't read your password, and neither can anyone who steals the database.

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

The usual way one user's data leaks into another's is a missing WHERE user_id = … somewhere in application code. Dumpling defends against that at the database layer instead of trusting every query to get it right: PostgreSQL row-level security is enabled on user data tables, and the role the application connects as cannot bypass it. A query that forgets its filter returns nothing rather than someone else's notes.

The database uses three separate roles — one that owns the schema and runs migrations, one for cross-user background jobs, and one for the application itself. Only the application role serves your requests, and it is the one that cannot bypass row-level security.

In transit and at rest

All traffic between your device and our servers is encrypted with TLS, with certificates renewed automatically. Internal service traffic doesn't leave the host.

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 pushed off-site to Cloudflare R2, which holds no key and cannot read them. We keep 7 daily, 4 weekly, and 6 monthly snapshots, so the oldest copy of anything is roughly six months.

There are two copies for two different disasters: one on the server itself, for fast recovery from a bad deploy or a corrupted table, and the encrypted off-site copy for the case where the server is gone entirely.

Abuse and rate limiting

The API is rate limited per user and per endpoint, with separate ceilings for expensive operations like AI calls. At the edge, repeated authentication failures and scanning behaviour get the source blocked automatically. Audit logs of security-relevant events are kept for 90 days.

Who can see your data

Dumpling is built by one person. Production access is limited to that person, is used for operating the service — deploys, migrations, investigating a fault — and is logged. Nobody browses your notes, and there's no internal tool for doing so.

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. We will credit you, and we'll respond like an adult — see below.

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. Our edge blocking will ban you, which helps nobody.
• 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.