Privacy Policy
FreeBusy ("we", "us", "the app") is an availability-sharing app that lets you share location, activity, and screen-time information with people you choose, at a granularity you control. This policy explains what data the app collects, how it is transmitted and stored, and the choices you have.
If you have questions, contact [email protected].
1. Core privacy principle
FreeBusy is end-to-end encrypted (E2EE).
All location, activity, and app-usage data ("signals") you share with your contacts is encrypted on your device using the Signal Protocol (X3DH + Double Ratchet for 1:1, Sender Keys for groups) before it leaves your phone.
We — the operators of the FreeBusy servers — cannot read your signals. The server stores only opaque ciphertext, public key bundles, and routing metadata (sender ID, recipient ID, timestamp). Decryption keys never leave your device.
This means:
- Even a full server breach cannot expose your location history.
- We cannot hand over your signal content in response to a subpoena, because we do not possess it in readable form.
- We cannot use your signal content for analytics, advertising, training, or any other purpose.
2. Data we collect
2.1 Account data (server-readable)
Required to operate the service:
| Data | Purpose | Source |
|---|---|---|
| Phone number | Account identity, OTP login, contact matching | You |
| Display name | Shown to your contacts | You |
| Email (optional) | Account recovery (not used for marketing) | You |
| Profile photo (optional) | Shown to your contacts | You |
| Device push token | Delivering notifications about new signals / invites | Android / FCM |
| Authentication tokens | Keeping you signed in | Generated server-side |
| Public key bundle | Letting contacts start an encrypted session with you | Generated on your device, public half uploaded |
2.2 Signal data (E2EE — server cannot read)
Generated on your device on a configurable cycle (default ~5 minutes when sharing is enabled) and encrypted separately for each recipient before upload. What goes into the payload depends on the per-contact level you set:
- Availability — derived status (Free, Busy, Driving, At Work, On a Call, Playing Media, Using Phone, Away, Sleeping).
- Location — one of: Off · Coarse (home / work / outside / traveling) · Area (city / neighbourhood) · Precise (latitude/longitude).
- App usage — one of: Off · Basic (total screen time today) · Category (time per category) · Full (top apps with names).
- Battery level and charging state.
- Phone call / media playback flag — no content, just "on a call" / "playing media" — derived from system audio mode, not from microphone.
Sensitive fields (precise location, foreground app names, per-app time) are only included when you explicitly opt in for that specific contact or group.
2.3 Contact matching
When you grant the Contacts permission, the app sends each contact's
phone number, saved display name, and saved photo to
/Contacts/check-registered so we can tell you which of
your address-book contacts are also on FreeBusy.
- Phone numbers are sent in plaintext over HTTPS for the lookup.
- Phone numbers of contacts who are not registered on FreeBusy are not retained beyond the lookup.
- For contacts who are registered and whom you choose to add, we store the saved display name and photo against the relationship so the app can show your saved label (e.g. "Mom") and photo — your device address book remains the source of truth.
2.4 Data we do not collect
- Microphone audio.
- Camera images (other than a profile photo you choose to upload).
- SMS or call content / logs.
- Web browsing history.
- Plaintext signal content (architecturally impossible — see §1).
- Advertising IDs.
- Behavioural analytics or telemetry tied to your identity.
3. How signals are delivered
- Your device runs a signal cycle (foreground service while sharing is on, with a WorkManager fallback every ~15 minutes).
- For each contact you have authorised, the app builds a payload at the level you configured for that contact, strips fields the contact is not authorised to see, then encrypts the payload with that contact's public key.
- The resulting opaque envelopes are uploaded to our API and delivered either via SignalR push or polled by the recipient's device on next open.
- The recipient's device decrypts the envelope locally and caches the plaintext in an on-device SQLite cache for charts / map / history.
- Once acknowledged, the server discards the envelope.
We retain ciphertext envelopes only long enough to deliver them and a short window for offline recipients to catch up.
4. Groups
When you join a group, the group admin sets a single sharing level for location and a single level for app usage that applies to all members. Your device requires you to acknowledge a level change before it begins emitting at the new level. Until you acknowledge, your device keeps emitting at the previously acknowledged level.
Group signals use the same E2EE channel as 1:1 signals (Sender Keys layered over your existing pairwise sessions). The server cannot read group signals either.
5. Blocking
Blocking another user is a one-way "stop receiving from them" action. It does not retroactively delete signals you previously sent them, and it does not stop your signals from reaching them via shared groups. To stop being seen in a group, leave the group.
6. Permissions
Android permissions the app requests, and why:
| Permission | Why it is needed |
|---|---|
| Location (fine, coarse, background) | Generating location signals at the level you choose |
| Foreground service (location, dataSync) | Keeping the upload cycle running reliably |
| Read contacts | Showing which of your contacts are on FreeBusy |
| Usage access (PACKAGE_USAGE_STATS) | App-usage signals — only collected when you enable Basic / Category / Full |
| Query all packages | Reading the human-readable name of the currently-foreground app |
| Notifications | Delivering signal / invite notifications |
| Ignore battery optimisations (optional) | Preventing the OS from killing the upload cycle |
| Boot completed | Resuming sharing after a reboot if you had it enabled |
| Wake lock | Letting the cycle complete its upload |
Each permission is requested at runtime in context, and revoking it in Android Settings is respected by the app on the next cycle.
7. Data retention
| Data | Retention |
|---|---|
| Account data (phone number, name, etc.) | Until you delete your account |
| Public key bundle | Until you delete your account or replace it |
| Encrypted signal envelopes | Until delivered + a short delivery window |
| Push notification tokens | Until you sign out or replace the device |
| OTP codes | 5 minutes (then expire) |
| Server logs (request metadata) | A short operational window |
Plaintext signals never reach the server, so there is no plaintext signal retention.
8. Deleting your data
You can delete your FreeBusy account at any time:
- From the app: Settings → Delete account, or
- By emailing [email protected] from the email on file.
Full step-by-step instructions and the exact list of data we delete vs. retain are on the dedicated account deletion page.
9. Children
FreeBusy is not directed at children under 13. We do not knowingly create accounts for users under 13. If you believe a child has created an account, email [email protected] and we will remove it.
10. Third-party services
| Service | Purpose | Data shared |
|---|---|---|
| Microsoft Azure (Central India) | Hosting our API, database, and SignalR | All server-side data described above |
| Firebase Cloud Messaging (Google) | Push notifications | Your push token and a small notification payload — never signal content |
| Google Play Services | Activity recognition, location services on your device | Per Google's privacy policy |
We do not sell or rent any data to third parties, and we do not share data with advertisers.
11. Security
- All network traffic is TLS-encrypted.
- Signal content is end-to-end encrypted using the Signal Protocol.
- Auth tokens and signal-cycle state are stored on your device using Android's hardware-backed keystore (via FlutterSecureStorage).
- Cryptographic session state is stored in a private SQLite database inside the app's sandbox.
- We follow industry-standard practices for server-side hardening, but no system is perfectly secure. Material breaches will be disclosed in accordance with applicable law.
12. Your rights
Depending on your jurisdiction (GDPR / DPDP / CCPA / similar), you may have the right to access, correct, port, or delete your personal data, and to object to or restrict processing. To exercise any of these rights, contact [email protected].
13. Changes to this policy
Material changes will be announced in the app and via the email on file (if provided) before they take effect. The "Last updated" date at the top of this document always reflects the current version.
14. Contact
Email: [email protected]