Home/Privacy Policy
Privacy, by architecture.
Safa is self-hosted. This page explains what the platform collects, where it lives and how it's protected — in plain language.
LAST UPDATED · SEPTEMBER 8, 2026
1. Overview
Safa is a self-hosted parental control platform. Unlike consumer monitoring products, no device data is sent to any vendor's cloud — everything the child app reports is transmitted over HTTPS directly to the server you (or your administrator) operate.
2. Information we collect
Console accounts: the name, email address and bcrypt-hashed password of parent and admin accounts created by the server administrator.
Paired device data: with each pairing, the child's Android device reports the signals the parent has access to in the console:
- Location fixes (on request and on geofence events, with accuracy data)
- Call logs (number, contact name, direction, duration) and SMS messages
- Keystrokes typed on the device, attributed to the source app
- App usage totals, install/uninstall events
- Camera frames (only when explicitly requested from the console)
- File listings and files you choose to download or preview
Pairing metadata: device model, Android version and an API token — stored as a SHA-256 hash, never in plain text.
Contact form: if you use the contact form, we store the name, email, subject and message you submit, plus the submission time and IP address for abuse prevention.
3. Where information is stored
All of the above is stored in the database and filesystem of this server — on hardware the operator controls. Backups, if any, are the operator's responsibility and never leave infrastructure they choose.
4. Who can access information
- Parents see only the devices paired to their own account — enforced server-side, not just in the interface.
- Administrators manage accounts, devices and platform health. The admin panel does not expose child data (messages, photos, locations) — it shows counts and status only.
- No one else. There is no vendor, no support portal and no third party with a pipe into your database.
5. Retention & deletion
Safa ships with automatic retention schedules that the operator can tune:
- Signaling messages (device polling traffic): deleted after 1 day
- Consumed commands: deleted after 7 days
- Keystroke logs: deleted after 90 days by default (
KEYLOG_RETENTION_DAYS) - Location history, call logs, SMS: kept until the device is unpaired or the parent/admin deletes them
- Contact form messages: kept until answered and archived by the administrator
Unpairing a device removes its association from the console; the operator may purge the underlying rows from the database at any time.
6. Children's information
Safa exists to help parents and legal guardians protect their own minor children. All device data is collected by and at the direction of the installing guardian, who is responsible for using it lawfully and in the child's interest.
7. How information is protected
- Pairing codes are stored as bcrypt hashes — they are never displayed twice and cannot be recovered
- Device API tokens are stored as SHA-256 hashes and can be revoked instantly
- Session cookies are HTTPS-only; strict security headers ship by default
- Pairing and device endpoints are rate-limited; weak or predictable pairing codes are rejected
- Child data responses are sent with no-store cache headers so logs, photos and locations never persist in browser or proxy caches
8. Cookies & local storage
The console uses one session cookie to keep you signed in. The only local-storage key is your light/dark theme preference. There are no advertising cookies, no cross-site trackers and no analytics scripts — all assets are served from your own server.
9. Your rights & contact
Because the data never left your server, exercising access, correction or deletion rights is straightforward: parents can manage devices from the console, and the server administrator can inspect, export or purge any records directly. Questions about this policy? Contact us — or reach the server operator directly.
This policy describes the Safa platform generally. If your deployment adds integrations or logging beyond the defaults, the operator must document them here.