PesaCastHow it stays yours.
What the app can see, where the data goes, how it is protected, and what has not been checked by anyone else yet.
What it can see
The SMS permission lets an app receive every incoming text. PesaCast keeps only messages whose sender is MPESA, parses them, and ignores the rest: they are not stored, not logged, not forwarded. The app does not log message text, tokens or secrets, and a test fails the build if someone adds code that does. It has no permission to send SMS, and no access to your contacts or files.
Where the data goes
- Phone to desktop, over Wi-Fi. Encrypted. The phone and desktop agree on fresh keys for every connection (ECDH on P-256), mixed with the pairing token so only the paired desktop can join, and each message is sealed with AES-256-GCM. The token itself is never sent over the network. Older, unencrypted versions are no longer supported.
- Phone to desktop, over Bluetooth. Short-range Bluetooth LE, with no application-level encryption. Use Wi-Fi if the room is not yours.
- Phone to your server (webhook). Only if you switch it on. HTTPS only, no redirects, signed if you set a secret, and the phone will not enable it until a test to that address has succeeded.
- To us. Nowhere. There is no PesaCast server, account or analytics. The desktop app asks GitHub whether a newer version exists.
What is stored on the phone
Pairing token, webhook token and signing secret are encrypted with a key held in Android’s secure storage. Backups and device-to-device transfer are switched off, so none of it is copied off the phone or restored onto another. Unsent webhook payments wait in a private file, for at most seven days, and are deleted once your server accepts them.
Installing safely
Newer releases publish a SHA-256 checksum next to the app. The setup script refuses to install a file that does not match, and for older releases uses the checksum GitHub itself recorded. Play Protect may ask about the app; choose to continue, and never switch Play Protect off for this.
What has not been checked
The Wi-Fi handshake has not had an independent review. It is built from standard parts (ECDH, HKDF, AES-GCM) and is covered by tests that both apps must pass against shared vectors, but the way the parts are combined is ours. The specification, threat model and the questions we most want answered are public. If you can review it, please do.
Anyone who learns your pairing token can impersonate either side. Regenerate it in the app to revoke access.
Reporting a problem
Please do not post a security problem in a public issue. Follow SECURITY.md, and do not include real transaction messages or tokens in a report.
Read it yourself
The code is public on GitHub, so you can check any of the above against what the app actually does.