Practices

Security

An offline app has a small attack surface: there is no account to steal and no server to breach. This page describes what that protects you from, and what it does not.

Last updated: 29 September 2026

How the app is built

No backend. There is no server, no API and no database we operate. An attacker has nothing of yours to take from us, because we hold nothing.
No accounts or passwords. Nothing to phish, reuse or leak.
Private app storage. Records live in a SQLite database inside the app’s sandbox. Android prevents other apps from reading it.
Device encryption. Modern Android encrypts app storage at rest and unlocks it with your screen lock. Using a PIN, pattern, password or biometric lock is the single most effective thing you can do to protect your records.
Minimal dependencies. The app ships with no analytics, advertising, crash-reporting or tracking libraries.

Keeping your numbers correct

Money is easy to get subtly wrong, so the app is deliberately strict about it:

Integer arithmetic. Amounts are stored in poisha (1/100 of a taka) as whole numbers, never as floating-point values, so rounding cannot silently drift.
Exact splits. Uneven divisions use a largest-remainder allocation, so the individual shares always add back up to the exact total.
Atomic writes. Multi-step saves, such as an expense with its payers and shares or a backup restore, run inside a single database transaction. They either complete in full or leave your data untouched.
Referential integrity. Foreign keys are enforced, and a person who still has expenses or payments recorded against them cannot be deleted out from under those records.
Versioned schema migrations. App updates migrate your existing database in order, inside a transaction, with a foreign-key check afterwards.

What this does not protect against

Please read this part

Exported backups are not encrypted. The JSON file is readable by anyone who opens it. Store it somewhere private and think before sharing it.
There is no in-app lock. Anyone who can unlock your phone can open the app and read everything in it. Use a device screen lock.
A rooted or compromised device offers no sandbox. On a rooted phone, other software can read the app’s database directly.
Losing the phone loses the data. There is no cloud copy to restore from. Export a backup regularly. That is the trade-off for an app that never uploads anything.

Restoring a backup is destructive

Restoring replaces all data currently in the app with the contents of the backup file. The app asks you to confirm first and shows the date the backup was made. There is no undo, so export a fresh backup before restoring an old one.

Backup files are checked before anything is replaced: a file that is not a valid Sholoana backup, or one made by a newer version of the app, is rejected rather than partially imported.

What we recommend

Lock your phone: A screen lock is what encrypts the app’s storage at rest.
Export a backup regularly: Especially before changing phones, factory resetting, or uninstalling.
Keep backups private: Treat the JSON file like a bank statement. It is not encrypted.
Install from Google Play only: Copies of Sholoana from other sources are not built or signed by us.
Keep the app updated: Updates carry fixes and schema improvements.

Reporting a vulnerability

If you believe you have found a security flaw, please email nodesynthesis@gmail.com with the details and steps to reproduce it. Please report it privately first and give us a reasonable chance to fix it before disclosing it publicly. We will acknowledge your report and keep you updated.