1. Who we are
Busnes.app is a d/b/a operated by Matthew Beacher. In this policy, “Busnes.app,” “we,” and “us” refer to Matthew Beacher doing business as Busnes.app. We publish the Ky apps and operate the services described in section 4. Contact us at privacy@busnes.app.
2. Apps this policy covers
This policy covers every app and service published by Busnes.app:
- KyPost for Android: Google Play package
org.kysecurity.mail. The same app is also published on GitHub asorg.kysecurity.mail.githuband for F-Droid asorg.kysecurity.mail.fdroid. - KyPost for Linux (Flatpak
com.kysecurity.mail), KyPost for iPhone and KyPost for Mac (bundle IDorg.kysecurity.mail, in testing), and the browser client that ships with KyPost Server. - KyAuth, the sign-in approver for KyIdentity: Android
org.kysecurity.authenticator(Google Play, GitHub and F-Droid builds), iPhone (in development) and Linux phones (kyauth.busnes, in development). - Self-hosted server software: KyPost Server, KyIdentity, KyNotes, KyCalendar, KyDrive, KyMessages, KyRecovery, KyDNS, KyPulse, KyYard, and the KyQuickStart installer.
- Services we operate: the KyPost and KyIdentity push relays, and this website.
3. How Ky apps handle data
Every Ky app is self-hosted. You, or someone you trust such as your employer or IT provider (the operator), runs the server. When an app sends your data “to the server,” it means that server and no other. We do not receive your mail, contacts, notes, files, calendars, messages or passwords just because you use our software.
The operator decides who has access, how long data is kept, and how it is backed up, so for data held on a server, the operator is responsible. If you are not the operator, ask them for their privacy notice. If you run your own server, you are the operator.
This policy explains what our apps send and to whom, and what we receive when an operator uses the services we run.
4. Services we operate
KyPost push relays (fcm.relay.kysecurity.org for Android, apn.relay.kysecurity.org for Apple devices). Google and Apple only deliver notifications to a published app through its publisher’s own credentials. The relays hold those credentials, so a self-hosted server can wake your phone without its own Google or Apple developer account. Your server talks to the relay; the app never does. An operator turns the relays on in the server’s configuration (the example configuration has them on) and can choose “App Pull” delivery instead, which uses no relay.
| What the relay receives | Why | What it keeps, and for how long |
|---|---|---|
| When a server first connects: the server’s public IP address and its hostname | Issue the server a relay key and limit abuse to one key per address | A key record (key ID, hostname, IP address, creation date) until the key is revoked. No automatic expiry. |
| For each notification: the device push token, the notification title and text, and a small data payload | Deliver the notification to Google or Apple | The text and payload are held in memory only while being delivered, then discarded. A one-way SHA-256 hash of the push token is stored with the key ID of the server that owns it, so no other server can push to your device. No automatic expiry. |
| Request metadata (time, server key ID, outcome, Google’s or Apple’s error reason on failure) | Run the service, diagnose failures, prevent abuse | Operational logs at Cloudflare, kept for up to 7 days. A count of notifications per server key and hostname, kept for 3 months. |
What is in a notification. By default, a new-mail notification says only “You have a new email” and carries a message ID, with no sender, subject or keywords. If you turn on notification previews for your account, the sender, subject and keywords are included. A sign-in approval request carries a challenge ID, a time and a two-digit match number; with previews on, it also includes the IP address and browser of the sign-in attempt. Messages you receive PGP-encrypted never show a preview. Anything in a notification passes through the relay and through Google or Apple in readable form, so leave previews off if that matters to you.
KyIdentity push relay. KyIdentity uses a relay of the same design to send KyAuth sign-in approvals. It receives the push token, a device ID, a user ID, a challenge ID and the purpose of the request, and keeps the same kinds of records for the same periods as the KyPost relays.
5. KyPost
KyPost connects your existing email account to a KyPost Server that your operator runs. The server fetches and sends your mail, and the apps sync with it.
| Data | Purpose | Where it goes | Required? |
|---|---|---|---|
| Email messages, folders, drafts, attachments, PGP keys | Read, write and send mail | Your KyPost server; a copy on the device | Required |
| Pairing details: device ID, push token, app version, and a device name. On Android that is the phone’s model (for example “Pixel 8”); on iPhone and Mac, the name you gave the device; on Linux, the computer’s hostname | Pair the device, deliver notifications, and let you recognise and remove the device in your device list | Your KyPost server. The push token also goes to Google (Android) or Apple (iPhone, Mac), and with each notification through our relay (section 4) | Required to pair |
| Your KyPost contacts | Address autocomplete and encryption keys, shown in your phone’s Contacts app | Your KyPost server; a copy on the device | Optional |
| Contacts from other accounts on your phone, such as Google contacts (names, email addresses, phone numbers, postal addresses, organisation, birthdays and other dates, relations, IM handles, websites, notes and groups; not photos) | Use your existing address book in KyPost | Uploaded to your KyPost server | Optional and off by default. You pick each phone account to upload; nothing is uploaded until you do |
| Contacts on a Mac or iPhone: KyPost contacts are written to the Contacts app, and new cards you create there are uploaded to your KyPost server | Keep your address book in sync | Your KyPost server | Optional; requires Contacts access |
| Notification history and app settings | Show recent notifications and remember your choices | Device only | Required |
On the device. KyPost for Android keeps mail and contacts in an encrypted database, keeps pairing secrets encrypted with keys in the Android Keystore, and excludes all app data from Android cloud backup and device-to-device transfer. Attachments you save go to your Downloads folder, where other apps can read them. With Hostile Location Protection on, mail is kept in memory only.
No Busnes servers. KyPost for Android connects to your KyPost server, to Google services on Google Play and GitHub builds (section 10), and to nothing operated by us. It has no analytics, crash-reporting or advertising SDK.
Things only you can trigger. Remote images in an email are blocked until you tap to show them; showing them contacts the sender’s servers and can tell the sender you opened the message. Scanning someone else’s PGP key QR code fetches their key from the server named in the code, which sees your IP address.
KyPost for iPhone, Mac and Linux keep secrets in the Keychain or the desktop’s Secret Service. KyPost for Linux receives notifications through UnifiedPush and never uses our relay. None of the KyPost apps include analytics or crash reporting.
What KyPost Server contacts. Besides your mail provider, the server checks GitHub hourly for new KyPost and Ollama releases, which shows GitHub the server’s IP address. When you send encrypted mail or look up a key, it asks the recipient’s domain (WKD) and then keys.openpgp.org for a public key, which tells them the recipient’s address. Mail classification uses a local model by default; if your operator points it at an outside AI service, that service receives the sender, subject and up to 2 KB of each message. If your operator enables Cloudflare receiving, incoming mail waits in the operator’s own Cloudflare account until the server collects it, then is deleted. CAPTCHA services are off unless the operator enables Cloudflare Turnstile or Friendly Captcha.
Accounts. Your KyPost account is created and held by your operator’s server, not by us. The app has no sign-up and creates no account with Busnes.app.
6. KyAuth and KyIdentity
KyIdentity is a self-hosted sign-in service. KyAuth is the phone app that approves sign-ins and generates one-time codes.
| Data | Purpose | Where it goes | Required? |
|---|---|---|---|
| Device name (Android: phone model; iPhone: the device name, which you can edit; Linux: “KyAuth on” plus the computer’s hostname), install ID, public key, push token, hardware attestation (Android key attestation, Apple App Attest) | Enrol the device as a trusted second factor | Your KyIdentity server. Attestation is checked against Google’s or Apple’s records | Required to pair |
| Sign-in approvals and denials | Approve or deny a sign-in | Your KyIdentity server | Required |
| One-time-code secrets and the device signing key | Generate codes and sign approvals | Device only, in the Android Keystore or iOS Keychain or an encrypted file, excluded from backups | Required |
KyIdentity stores accounts, devices, sessions, and audit events, including the IP address and browser of each sign-in. Audit events are deleted automatically after 180 days. By default it also contacts Google’s Android attestation revocation list and, for Linux phones, the UBports push service, which receives encrypted payloads only.
On iPhone and Linux phones, unpairing in KyAuth removes the pairing from the phone only; ask your operator, or use your KyIdentity account page, to remove the device from the server. KyAuth for Android also asks the server to delete it, as described below.
KyAuth for Android
KyAuth for Android (org.kysecurity.authenticator) only works with a KyIdentity server that you or your organization runs. Busnes.app receives no KyAuth data, apart from what our push relay needs to deliver Firebase sign-in requests (section 4). Whoever operates your KyIdentity server controls the data KyAuth sends to it; send requests about that data to them.
| When | What KyAuth sends to your KyIdentity server | Why |
|---|---|---|
| Pairing | Your KyIdentity user ID, the phone’s model name, a random installation ID, the device’s public key, an Android Key Attestation certificate chain, and the push address (a Firebase token, or a UnifiedPush endpoint and its encryption keys) | To pair this phone with your account and let the server send it sign-in requests. The attestation chain proves the device key lives in secure hardware; it includes the bootloader state, OS patch level, KyAuth’s package name and its signing certificate. |
| Answering a sign-in request | The request ID, the number you picked, approve or deny, and a signature from the device key | To approve or deny the sign-in. The signature shows the answer came from this phone. |
| Signing in to another suite app, such as KyPost | A signed device assertion | To get an identity token for that app. KyAuth passes the token to the app only after you approve with biometrics or screen lock. |
| Unpairing | A signed request | To ask the server to delete this phone’s record. |
Google services. Only the Google Play and GitHub builds include these; the F-Droid build contains no Google code. See Google’s privacy policy.
- Firebase Cloud Messaging, only if you pair using Firebase delivery. Google then receives a Firebase installation ID, the FCM token, the app version and basic device information, to deliver sign-in requests. Nothing is sent to Firebase before you pair, in demo mode, or if you choose UnifiedPush. The token is deleted when you unpair, reset the app or switch to UnifiedPush. Firebase push messages carry your device ID and user ID through Google unencrypted. UnifiedPush messages are end-to-end encrypted (RFC 8291), and the distributor cannot read them.
- Google code scanner (ML Kit, run by Google Play services), only when you tap Scan. Google may collect device information, the app’s package name and version, an installation ID and performance diagnostics. You can type codes in instead.
What never leaves your phone. One-time-code secrets and account names, kept in an encrypted vault that opens only with biometrics, screen lock or your optional PIN; your PIN; and biometric data, since KyAuth only learns whether the check succeeded or failed. KyAuth has no backup, export, sync, ads, analytics or crash reporting.
Keeping and deleting data.
- On your phone: “Unpair” removes the pairing, the device key and the push token. “Reset KyAuth” erases everything. Five wrong PINs erase everything. Uninstalling erases everything.
- On the server: unpairing asks KyIdentity to delete the device record, on servers that support it. You can also remove the phone on your KyIdentity devices page, or ask your server operator.
- At Google: under Google’s Firebase privacy and security terms and its ML Kit data disclosure.
Security. All traffic to KyIdentity uses HTTPS only, and KyAuth follows no redirects. KyAuth blocks screenshots and Android backup. KyAuth is not directed to children under 13.
7. Other Ky server apps
KyNotes, KyCalendar, KyDrive, KyMessages, KyRecovery, KyDNS, KyPulse and KyYard are server software with a browser interface. None of them ships a phone app or contacts a Busnes.app service by default. Their browser interfaces load no third-party scripts and use cookies only to keep you signed in and protect forms, plus local storage for your light or dark theme.
- KyNotes encrypts notes and attachments in your browser before they reach the server.
- KyMessages keeps chats on your server. Federation with other chat servers is off unless the operator enables it, and push notifications carry no message content.
- KyRecovery stores encrypted backups sent by other Ky apps and copies them only to destinations the operator chooses.
- KyDNS by default forwards DNS lookups it cannot answer to Cloudflare and Quad9 over encrypted DNS, and downloads a public blocklist from GitHub once a day. The operator can change both.
- KyPulse sends alerts only to webhooks the operator configures.
- KyYard contacts container registries only when the operator checks for updates or sets an update policy.
- KyQuickStart downloads container images and, only if the operator chooses a tunnel, configures Cloudflare Tunnel or frp.
Accounts in these apps are created and deleted by the operator, usually through KyIdentity.
8. App permissions
- Contacts (KyPost for Android): to show your KyPost contacts in the phone’s Contacts app, and, only for phone accounts you choose, to upload contacts to your KyPost server. You can deny it and still use mail.
- Notifications (KyPost, KyAuth): to tell you about new mail and sign-in requests.
- Camera: to scan pairing and PGP key QR codes. On Google Play and GitHub builds, Google’s code scanner handles the camera and KyPost does not hold the camera permission. The F-Droid builds and KyAuth for iPhone ask for the camera directly. Images are not stored or sent.
- Biometrics (fingerprint or face): to unlock the app and approve sign-ins. Your biometric data never leaves the operating system; the app only learns whether the check passed.
- Network, background work and start at boot: to sync and receive notifications.
9. Tips and payments
KyPost for Android on Google Play lets you leave an optional tip, either once or as a monthly subscription. Tips unlock nothing; every feature is free. Google Play processes the payment under Google Payments’ privacy notice. We never see your card details, and the app does not link a tip to your email or KyPost account. Google gives us an order record (order ID, product, price, country and status) for accounting and refunds, which we keep as long as tax law requires. Cancel a monthly tip in Google Play under Payments and subscriptions.
KyPost for iPhone and Mac offer the same optional tips through the App Store, processed by Apple under Apple’s privacy policy; we receive sales reports, not your identity.
Builds from GitHub and F-Droid, and KyPost for Linux, link to an external Buy Me a Coffee page instead. Anything you give there is handled under Buy Me a Coffee’s own policy.
10. Third parties
| Provider | When | What it receives |
|---|---|---|
| Google Firebase Cloud Messaging (policy) | KyPost and KyAuth Android, Google Play and GitHub builds | A Firebase installation ID, push token, app version and device details (model, OS version) from the app; notification text from our relay |
| Google code scanner, part of ML Kit (data disclosure) | Scanning a QR code on Google Play and GitHub builds | Google’s own diagnostics: device model, OS version, app package and version, performance data, and an identifier. Not the scanned code or the image |
| Google Play Billing (policy) | Only if you tip | Your purchase |
| Apple Push Notification service and App Attest (policy) | KyPost and KyAuth on Apple devices | Push token and notification text; for KyAuth, an attestation of the app at pairing |
| Cloudflare (policy) | Hosts our push relays | Everything the relay receives, as described in section 4 |
| Your UnifiedPush distributor, such as ntfy (UnifiedPush) | F-Droid builds, or if you choose UnifiedPush | Notifications from your server, encrypted end to end; our relay is not used |
| GitHub (policy) | KyPost Server update checks; the KyDNS blocklist download | The server’s IP address |
| keys.openpgp.org (policy) | KyPost Server looking up a recipient’s public key | The recipient’s email address and the server’s IP address |
| UBports push (UBports) | KyAuth on Linux phones | Encrypted sign-in requests from your KyIdentity server |
The F-Droid builds contain no Google code. Some of these providers process data outside your country under their own safeguards.
11. What we do not do
- We do not sell or rent personal information, or share it for cross-context behavioural advertising.
- Our apps contain no advertising, and no analytics or crash-reporting SDK. The Google services in section 10 collect their own diagnostics; we do not receive them.
- We do not track you across other companies’ apps or websites.
- We do not use your data to train AI models. KyPost’s mail classifier runs on the model your operator configures, not on a service of ours.
12. Deleting data and unpairing
- Unpair KyPost for Android in the app. It tells your server to forget the device, deletes the push token and Firebase installation ID, and deletes mail, contacts, keys and settings from the phone. Uninstalling also removes app data from the phone, but does not tell the server.
- Stop contact upload by turning off contact sync or unticking an account. This stops future uploads; contacts already uploaded stay on your KyPost server until you delete them there.
- Server data (your mail account, contacts, notes, files, sign-in history) is held by your operator. Delete individual items such as messages and contacts in the app or web interface, or ask your operator. KyPost Server can deactivate an account, which revokes its access, but does not yet delete the account’s stored data; the operator removes that from the server.
- Data we hold. We hold no account for you. Once a device is unpaired, the hashed token at the relay refers to a token that no longer works. Operators can ask us to delete a server’s relay key and its token records, and anyone can ask us to delete correspondence, by writing to privacy@busnes.app. We aim to respond within 30 days.
13. Security
Our apps connect only over HTTPS, encrypt stored data on the device, and keep keys in the operating system’s secure storage. The relays never write notification text to storage, hold no admin interface, and keep their credentials as encrypted secrets. No system is perfectly secure. Report vulnerabilities to privacy@busnes.app or through the project’s GitHub security page.
14. Your rights
Depending on where you live, you may have rights to access, correct, delete, restrict or receive a copy of personal information; to object to certain processing; to withdraw consent; and to complain to a privacy regulator. We rely on providing the service you asked for, and on our legitimate interest in keeping it secure, to process the limited data described in section 4.
Send requests about data we hold to privacy@busnes.app. For data on a self-hosted server, contact that server’s operator. We may need to verify that a request comes from you or from the server concerned.
15. Children
Our apps and services are not directed to children under 13, and we do not knowingly collect personal information from children. If you believe a child’s information reached a service we operate, contact us and we will delete it.
16. This website and correspondence
busnes.app is a static site with no advertising, analytics, cookies, accounts or embedded third-party content. Its host receives ordinary request logs (IP address, requested page, referrer, browser and time) to deliver and protect the site. The theme switch stores your light or dark choice in your browser only.
If you email us or contact us through GitHub, we use your name, address and message to reply, provide support, and handle security reports. Email providers and GitHub process this under their own terms. Please do not send passwords, keys or other credentials by email.
17. Changes to this policy
We post changes here and update the date at the top. If a change materially affects what our apps send or what our services keep, we will also announce it in the affected apps’ release notes before it takes effect.
18. Contact
Matthew Beacher, d/b/a Busnes.app. Privacy questions and requests: privacy@busnes.app