Privacy & security

Where each copy of your data lives and what protects it, layer by layer.

On your device

The working copy, the only thing the app ever reads, is in your browser's storage. No account is required to use Bongo, and the JSON export in Settings moves everything out at any time. File attachments stay on the device that added them and never upload. An unlocked device can read its own browser storage, so device full-disk encryption and a lock screen matter here; a web app can't substitute for them.

In transit

Every network call targets HTTPS, and the site sends strict transport headers: two years of forced HTTPS after the first visit, and a Content-Security-Policy that runs scripts from this origin only and lets the page talk to exactly two outside hosts (the sync backend and the AI helper). That policy is the containment for injected scripts, and it's also why there are no analytics or trackers to block; the page can't call them.

On the server, if you sign in

Sync stores each item as one row in Postgres at Supabase, isolated per account by row-level security: the database itself refuses to show one account another account's rows, and an automated check in the project's test suite fails the build if any table is ever added without that protection. The platform encrypts disks with AES-256. Without end-to-end encryption, item text is readable by the platform operator, as with most sync services. End-to-end encryption removes that access.

End-to-end encryption, if you turn it on

In Settings, set a passphrase and everything you sync is encrypted on your device before upload: AES-GCM, under a key derived from your passphrase with 600,000 rounds of PBKDF2. The server stores text it cannot read, and each new device asks for the passphrase once. The honest trade: nobody can reset that passphrase, including Bongo. If you forget it, recovery means erasing the server copy and re-uploading from any device that still holds your data, or from a JSON export; exports stay unencrypted for exactly that reason, so treat the file like the data.

The AI helper

"Break it down" and the calendar's plain-words entry send only the text involved to a small relay that holds the API key server-side, pins the prompt and the model, and caps each account at 20 calls a day. The model has to read the text to break it down, so those features transmit what you give them even with end-to-end encryption on; the rest of your data is never in the request. Your API keys are never asked for, and the browser cannot even reach the model provider directly.

Reporting a problem

Found something? Email example@example.com with the details, and keep them private rather than posting publicly, so a fix can go out before the problem spreads.