Privacy Policy

1. Introduction

Salva ("we," "our," or "us") is a parental screen-lock and household management application for Android that helps parents protect their children's screens from accidental touches, manage screen time, monitor on-screen content, and coordinate rules across multiple family devices. This Privacy Policy explains what information we collect, how we use it, how we store and protect it, and your rights regarding your data.

Salva is set up and controlled by parents and caregivers: a parent creates the account, pairs the devices, and controls all settings, rules and monitoring. Children use a paired child device — both the protected device screen and Salva's own child screens, which are described in Section 5.

Who is responsible for your data. Salva is operated by Anthony Mallah from Abu Dhabi, United Arab Emirates. He is the data controller for the personal data described in this policy — the person who determines what data is collected, for what purposes, and how it is used. Requests about the rights described in Section 10 should be sent to the contact address in Section 13.

By installing or using Salva, you agree to the practices described in this Privacy Policy.

2. Information We Collect

2.1 Data Stored On-Device Only (Never Uploaded)

The following data is stored exclusively on your device and is never transmitted to any server. Where a row notes that a summary or an excerpt of the same activity is sent to the cloud, that summary or excerpt is listed in Section 2.2 and is not part of the data described here:

2.2 Data Stored in the Cloud

The following data is held in our cloud backend (hosted on Supabase). Most of it exists only once you create or join a household; the rows on account information, sign-in sessions, free-trial records, support requests, and the tester and waitlist lists apply whether or not you have a household:

2.3 Data We Do NOT Collect

• No advertising or ad tracking IDs
• No precise location data — Salva asks for no location permission and collects no GPS or device location. The IP address recorded on a device record is truncated by our database before it is stored, and we derive no location from it — Salva makes no IP-geolocation lookup of any kind, and no city, region or country is worked out from any address we hold. Separately, our authentication provider records the full IP address of each sign-in session as part of managing that session (see Section 2.2 and Section 7)
• No contacts, call logs, or messages
• No photos, videos, or microphone recordings — the camera permission is used exclusively for QR code scanning during household pairing and is declared as optional
• No browsing history
• Opt-in product analytics only — we use Firebase Analytics for product analytics, but only when you explicitly opt in via Account → Privacy & Data. Analytics is disabled by default. When enabled, we log a small fixed set of product events — around fifteen of them — covering onboarding and setup steps such as starting and completing onboarding, viewing the permission setup screen and enabling the Accessibility Service; the first time protection is activated; sessions started; mode switches; blocked taps; "aha moment" indicators; the day number of a lifecycle message shown or dismissed; and subscription events such as viewing the paywall, starting and ending a trial, and purchasing a subscription. No email, name, device identifier, household identifier, screen content, or other personally identifying information is included in any event. We do not use Mixpanel, Amplitude, or any other third-party analytics SDK. We also use Firebase Crashlytics for crash and error reporting (no user-identifiable data is collected).
• No personal content from screen scans — Screen Sentinel processes text entirely on-device. When a keyword match triggers an alert, the only thing from the screen that is stored is a short snippet of the matched text, which the app trims to at most 200 characters on the device before sending it; the alert is stored alongside a category label, a severity label and the app name, and is auto-deleted after 7 days. No full raw screen-text dump or continuous screen contents leave the device.
• Nothing from inside another app — As disclosed in Section 2.2, the heartbeat includes the package name of the app currently in the foreground (e.g., com.example.app), and the device separately reports the names of the apps installed on it. What we do not collect is anything from inside another app: no in-app activity, no screen contents beyond the Screen Sentinel snippet described above, no notification text, no messages, and no account details or other user data belonging to any third-party app. The latest heartbeat value overwrites the previous one, so the heartbeat itself keeps no rolling history. Three related things are collected and disclosed separately rather than here: the list of apps installed on the device, covered by Installed app inventory in Section 2.2; time spent per app, covered by Activity history in Section 2.2; and matched on-screen text, covered by the Screen Sentinel bullet above.

3. How We Use Your Information

We use the information we collect to:

• Provide core functionality — screen protection, touch blocking, mode switching, and scheduled protection
• Enable household management — let parents monitor and manage child devices remotely through the Family Dashboard
• Deliver content alerts — notify parents of potentially concerning on-screen content detected by Screen Sentinel
• Sync rules and rewards — keep Smart Rules and Screen Time Rewards consistent across household devices
• Verify subscriptions — confirm your subscription status and entitlements through Google Play Billing
• Prevent abuse — detect and mitigate fraudulent device pairing, device farming, and stolen entitlements
• Show parents what is on a child's device — list the apps installed on a child device so a parent can choose which to whitelist, pin, or write a rule for
• Answer your support requests — read and reply to messages you send us from inside the app
• Provide technical support — use device metadata for debugging and troubleshooting

We do not use your data for advertising, profiling, or sale to third parties.

4. Permissions We Request

All permissions are used solely for their stated purpose. The Accessibility Service is used exclusively for screen protection, touch interception, and content monitoring — never for collecting personal information.

5. Children's Privacy

Salva is set up and controlled by parents: a parent creates the account, pairs the devices, and sets every rule and limit. A paired child device is also used directly by the child, on the screens described below. We take children's privacy seriously:

• Child devices do not require a Google account. They are paired to a household via QR code or 6-digit pairing code with the physical presence of a parent.
• No IP address is stored for child devices (lastIp and lastRegion are set to NULL by a database trigger). Parent devices' IP addresses are truncated by our database before storage (Section 7) and purged on the schedule in Section 8. We derive no location from any of them.
• The child device itself is identified pseudonymously — by a SHA-256 hash of device identifiers, not by a name and not by an account. The child's own details are held separately, in the child profile described in the next bullet.
• A child's first name and approximate age. When a child device is paired, the app asks for the child's first name and age so that parents can tell devices apart in the Family Dashboard and so the child sees their own name on their device. It is entered on the child's device, as one of the pairing steps described above, and it is stored in our cloud (see Section 2.2). In the app it is shown to the adults signed in to that household account and to any additional guardian a parent has invited for that child; the administrative access described in Section 7.1 also reaches it. Giving an age is optional; a name is required to complete the profile step, and the profile step itself can be skipped.
• Content alerts from child devices include a category label, a severity label, the app name, and a short snippet of the matched text, which the app trims to at most 200 characters on the device before sending it. Nothing else read from the screen is included, and the alerts are automatically purged after 7 days. The same channel also carries requests a child chooses to send a parent from Kid Session, a note when an emergency unlock is used on the device, and — where Screen Time Rewards is switched on — a request for the parent to approve a reward task the child has marked as done; all three are described in Section 2.2.
• Screen Sentinel processes all screen text on the child device. Nothing from the screen leaves it unless a keyword matches; when one does, the alert carries the short excerpt described in the previous bullet and nothing else the scan read.
• Monitoring alerts go to the parent, not to the child. Content alerts raised by Screen Sentinel are delivered only to parent devices, and the child device shows no popup, notification or interruption when one is raised. That is a statement about the monitoring features specifically. Salva also has screens a child uses directly, and they are described in the next bullet.
• What a child sees on their own device. A paired child device runs Salva's own child screens: a home screen that greets the child by the first name in their profile, an "Earn Time" screen, a screen for sending the parent one of the fixed requests described above, and a help screen. Where a parent has switched on Screen Time Rewards — a paid feature, off unless the parent sets it up — Earn Time shows the reward tasks that parent has written, each with the emoji, name, description, bonus minutes and daily cap the parent gave it, alongside three running totals: unspent bonus minutes, minutes earned today, and the number of consecutive days on which the child earned time, which the app calls a streak and shows as a count of days. When that streak is longer than one day, the home screen repeats it in the greeting. Tapping "I Did It!" on a task sends it to the parent for approval and shows the child an on-screen confirmation that it was sent; the bonus minutes are added only after the parent approves. These are screen-time features a parent turns on and controls, and what they record is listed in Section 2.2 under Screen Time Rewards and screen-time limits, under Device heartbeat, and — for the approval request itself — under Content alerts and child requests. Reward tasks and the log of completions have no automatic expiry and are kept until the parent deletes them or the device, household or account they belong to is deleted; the three running totals are held on the child's device and overwritten in the heartbeat.

COPPA scope statement. We do not knowingly collect personal information from children as defined by the U.S. Children's Online Privacy Protection Act (COPPA — name, address, phone number, email, photo, audio recording, geolocation, persistent identifier tied to a real-world identity, or other identifier that permits the physical or online contacting of a specific child). The data we do collect from a paired child device — a pseudonymous SHA-256 device fingerprint, a device-bound token, household identifier, the child profile set up during pairing (the child's first name and, if they are given, an approximate date of birth and a gender, described in Section 2.2), the list of apps installed on the device, the protection settings in effect on it, the reward tasks a child marks as done where a parent has switched Screen Time Rewards on, and the protection and activity telemetry described in Section 2.2 — is used solely to operate the parental-control service the parent has set up. Content alerts may include a category label, a severity label, the app name where text was matched, and a short text snippet from screen content read by the Accessibility Service, which the app trims to at most 200 characters on the device before sending it; these snippets can incidentally contain text the child saw on screen, are shown in the app only to the adults signed in to that same household account — a guardian invited for the child cannot reach them — are within reach of the administrative access described in Section 7.1, and are auto-purged after 7 days. We never sell, share for advertising, or otherwise disclose child-device data outside the household, other than where a parent invites another adult as a guardian for that child — in which case the invitation names the child concerned (see Section 6), and a guardian who accepts can see records we hold about that child, including the child's profile, the child's device, any custody schedule set for the child, summaries of the child's activity and app usage, and the protection settings in effect on the child's device. Content alerts are not included in that access. We do not direct any advertising to children.

6. Third-Party Services

We do not use:

• Advertising networks (no AdMob, no ads of any kind)
• Mixpanel, Amplitude, or any third-party analytics service other than the opt-in Firebase Analytics described above
• Social media tracking pixels
• Any data broker services
• Advertising IDs (we do not collect Google Advertising ID or any equivalent)

Note on Firebase Crashlytics: used for crash and error reporting only. It does not collect user-identifiable data, browsing activity, or analytics events. Crashlytics data is retained for 90 days. Debug-build crashes are not collected (setCrashlyticsCollectionEnabled(false) in debug).

7. Data Security

We implement the following security measures to protect your data:

• On-device encryption — Sensitive local data such as auth and billing tokens is stored primarily in Android's EncryptedSharedPreferences backed by the Android Keystore. Clean Screen knock patterns are also stored this way on supported devices, but may fall back to app-private SharedPreferences if Android Keystore / EncryptedSharedPreferences fails. A plaintext recovery copy of the device token and household identifier is retained for up to 30 days to handle Keystore corruption; this recovery copy is protected only by Android's app-sandbox file permissions and is not separately encrypted. Non-sensitive general preferences use standard Android DataStore.
• Transport encryption — All communication between the app and our cloud backend uses HTTPS/TLS
• Pseudonymous identifiers — Device fingerprints are SHA-256 hashed before storage
• IP truncation on device records — The IP address held on a device record is truncated by our database before it is stored: an IPv4 address is reduced to its /24 prefix, and an IPv6 address to its first three hextets. For a child device, no IP address is stored at all. This applies to the device record; our authentication provider separately records the full IP address, and the app or browser user agent, of each sign-in session as part of keeping you signed in (Section 2.2)
• Token-based authentication — Device-bound refresh tokens with Keystore binding for entitlement verification
• Row-level security — Supabase row-level security (RLS) policies restrict what an authenticated end user can read and write. The general rule is that a user reaches only data scoped to a household they belong to. There is one deliberate exception, and it is a feature rather than a gap: an adult a parent has invited as a guardian for a particular child can read the records about that child listed in Section 5 from their own account, without being a member of that child's household. Server-side functions (SECURITY DEFINER stored procedures and our backend edge functions) run with elevated privileges and intentionally bypass RLS in order to validate device tokens, resolve household membership, and perform administrative operations; their access patterns are constrained by their own authentication and authorisation logic rather than by RLS.
• Integrity verification — Google Play Integrity API checks ensure the app is running on genuine, untampered devices
• Anti-abuse monitoring — Automated detection of suspicious pairing patterns and device farming

7.1 Who at Salva Can Access Your Data

Salva is operated by one person — the developer named at the top of this policy and in Section 13. To keep the service running, that person can access the cloud data described in Section 2.2 directly, using an administrative credential: to investigate a sign-in that fails, a subscription showing the wrong plan, a device that will not pair, or a fault you have reported to us. That administrative access is not limited by the row-level security described above, and it is technically capable of reaching any record in our database.

We would rather be specific than reassuring about what that means. Because the credential is unrestricted, the same session used to answer an ordinary billing question could also read any child's name, schedule, or device history. Our software does not currently prevent that. What limits it is the practice set out below, and the fact that we have written that practice down.

• Named queries with a stated scope. Routine support and diagnostic questions are answered from a fixed set of reviewed, read-only queries rather than by ad-hoc database access. Each one records, in writing, the fields it deliberately does not return, and children's names, screen-content snippets, activity and app-usage detail, and authentication and billing credentials are named on those lists. None of those queries returns any of them, and none of them reads the contents of your messages to us or a child's custody schedule at all.
• A written record before we look. Before running one of those queries, the operator records what is being looked at and why, in a log the database refuses to let anyone edit, and refuses to let anyone delete from except the scheduled retention sweep described in Section 8. That log records that a record was consulted, not what it said: it has no attachment, no message body and no general-purpose data field, and the operator writes only two things into it — a short name for the operation, which the database constrains to a lowercase identifier, and a short written reason, which by our standing rule states why the record was consulted and never what was seen (see Section 8).
• Nothing leaves. Support access is used only to answer your request or keep the service working. It is never used for advertising or profiling, and our rule is that household or child data is not copied out of the database into tickets, spreadsheets, exports, or screenshots.

We should be equally plain about the limits, because they are real. All three measures above are operating practice, not technical restrictions. The administrative credential itself is unrestricted; nothing in the system compels the use of the named queries; and the record of access exists only if the operator writes it. They are rules we hold ourselves to, adopted in August 2026, not controls the software enforces.

We are building the enforced version — individually named operators, each holding only the permissions their role needs, and an audit record written automatically by the system rather than by a person. We will have that in place before anyone other than the developer named in Section 13 is given access to production data. Until then, the only person at Salva who can reach your data is that same named individual.

Telling you when we look. Today, the only person at Salva who can access production data is the developer named in Section 13, and that access happens only to operate the service or to answer a request you have made. When we introduce the ability for a support operator to view personal details that are otherwise hidden from them — a child's name, or a parent's email address — we will notify the account owner each time it happens, other than in the limited circumstances described in that notice policy when we publish it.

8. Data Retention & Deletion

Automated Retention Schedules

Records of Staff Access

When someone at Salva consults an account, we keep a record that they did so: an identifier for what was consulted — an account, a device, a household, a child's profile, or a support request you have sent us — together with the time, the name of the operation performed, and the reason the operator gave for it.

We keep these records for 24 months. That is longer than we keep most of what such a record points at — content alerts last 7 days, truncated IP addresses 30 days, abuse flags 180 days, device removal logs a year — but it is not longer than everything we hold: purchase-verification records are kept for up to 7 years, and information such as your account details is kept for as long as your account exists. We chose 24 months because a record of who looked at your data is of little use if it expires before anyone thinks to ask the question.

These records are not erased when you use "Delete My Data". Two reasons. First, they describe our own staff's conduct rather than you. Second, they hold no copy of the data that was consulted: the record has nine fields, none of them built to carry content from your account — there is no attachment, no message body, no general-purpose data field — and nothing in our software copies any part of your record into one. Two of the nine are typed by the operator. One is a short name for the operation, which the database constrains to a lowercase identifier so that it cannot become a second field of prose. The other is a short written justification, capped at 400 characters, which the operator types to explain why the look was necessary; our standing rule is that it states why, never what was seen. The identifiers the record carries simply stop resolving to anything once your data is gone. We keep these records on the basis of our legitimate interest in maintaining an auditable record of who has accessed personal data, which we consider necessary to the integrity of our own access controls. If you wish to object to this, contact us at the address in Section 13.

User-Initiated Deletion

You can delete your data at any time through the following methods:

• Clear individual alerts — Manually remove specific content alerts from the parent dashboard
• Remove a device from household — The device's record is marked inactive and it stops syncing with the household. This step does not erase that device's cloud data: its heartbeat, alerts, activity history, settings and rewards remain under the retention schedules above until they expire, or until the household or the account is deleted. A removal log holding the device's fingerprint is created and kept for 1 year. The child profile attached to that device is deleted, unless another adult also holds active guardian access to that child
• Delete household — Settings → Account → Manage Household → "Delete Household" removes all household data from the cloud with cascading deletion of all associated records
• Delete My Data — Settings → Account → "Delete My Data" deletes your account and all associated household data from our cloud servers: your devices are removed (and with them all stored IP and region fields), and your household's abuse-detection records and device removal logs are permanently deleted. The app then wipes all local data on this device — sign-in tokens, app preferences, Screen Sentinel state, and the cached alert history — and signs you out. Uninstalling the app removes any remaining local files. Some records are kept back from this deletion, as described in the retention schedule above. Purchase-verification records are retained for billing and tax compliance, with your user and household identifiers removed. Records of staff access to your account are retained for 24 months, because they describe our own staff's conduct and hold no copy of your data. If you have written to our support team, we do not delete the request outright, because we use the record to recognise repeat abuse of free trials and refunds. Instead we redact it: the link between the request and your account is removed, and your name, the email address on the request, your subject line and your message are overwritten with a fixed marker — the text you wrote is destroyed and cannot be recovered. What remains is the category you chose, the device model, Android version and app version, whether the account was on a premium plan or a trial at the time, the dates, and whether the request was resolved; if the category was not one of the options the app offers, it is cleared as well. Redacting a request does not restart the 12-month clock above, so a redacted request is still deleted 12 months after it was last updated. This applies to support requests we can link to your account — if you wrote to us while signed out, or gave a different email address from the one on your account, tell us that address and we will redact those too. Also kept are security event records, backend error records, the log of subscription notifications from Google Play, and the tester and waitlist email lists, because none of them is attached to your household record. If you would like any of these removed as well, contact us at the address in Section 13.
• Uninstall the app — Removes all local data (settings, reports, patterns) from your device. Cloud data persists until you use one of the deletion options above or until automated retention schedules expire.

9. Subscriptions & Payments

• All payments are processed exclusively through Google Play Billing. We never collect or store your credit card number, bank account details, or other financial information directly.
• Salva offers a free tier with core protection features — no ads, no hidden charges.
• Premium plans (Individual, Family, Family+) are available. The Individual plan covers up to 2 devices total (including the parent device). Family plans (6 devices) and Family+ plans (12 devices) add household management features including Family Dashboard and Remote Control.
• All premium plans include a 7-day free trial, managed by the app. Only one trial is allowed per Google account. There is no automatic charge at trial end — when the trial expires, Salva reverts to the Free plan unless you actively choose a paid subscription.
• You can manage or cancel your subscription at any time through the Google Play Store.

10. Your Rights

Depending on your jurisdiction, you may have the following rights regarding your personal data:

• Right of access — Request a copy of the data we hold about you
• Right to rectification — Request correction of inaccurate data
• Right to erasure — Request deletion of your data (available in-app via "Delete My Data"; some records are kept back from that deletion, as described in Section 8)
• Right to data portability — Request your data in a portable format
• Right to restrict processing — Request that we limit how we use your data
• Right to object — Object to specific data processing activities
• Right to withdraw consent — Withdraw consent at any time by disabling permissions, removing devices, or deleting your account

To exercise any of these rights, contact us at [email protected]. We will respond within 30 days.

For EU/EEA residents (GDPR): Our legal bases for processing data include: (a) performance of a contract (providing the service you subscribed to), (b) legitimate interests (security, anti-fraud), and (c) consent (optional features like Screen Sentinel alerts).

For California residents (CCPA/CPRA): You have the right to know what personal information we collect, the right to delete your personal information, the right to opt out of the sale of your personal information, and the right to non-discrimination for exercising your privacy rights. We do not sell personal information. To exercise your rights, use the in-app "Delete My Data" feature or contact us at [email protected]. We will verify your identity and respond within 45 days.

11. International Data Transfers

Our cloud backend is hosted on Supabase infrastructure in the eu-central-1 AWS region (Frankfurt, Germany — within the European Union). For users located in the EU/EEA, your primary household data does not leave the EU for storage purposes. For users located outside the EU/EEA, your data is transferred to and stored in the EU; we rely on the standard Supabase Data Processing Addendum (DPA), which incorporates Standard Contractual Clauses (SCCs) where applicable, as the safeguard for any onward processing by Supabase's subprocessors. Supabase publishes its current subprocessor list at https://supabase.com/legal/subprocessors. Firebase services described in Section 6 are operated by Google LLC and are subject to Google's published transfer mechanisms. Salva is operated by Anthony Mallah from Abu Dhabi, United Arab Emirates.

12. Changes to This Privacy Policy

We may update this Privacy Policy from time to time. When we make material changes, we will:

• Update the "Last Updated" date at the top of this policy
• Notify users through an in-app notification or update notes

We encourage you to review this Privacy Policy periodically. Your continued use of Salva after changes are posted constitutes your acceptance of the revised policy.

13. Contact Us

If you have any questions, concerns, or requests regarding this Privacy Policy or our data practices, please contact us:

Email: [email protected] Developer: Anthony Mallah Website: https://getsalva.com App: Salva for Android

This privacy policy applies to the Salva Android application (package: com.salva.app) distributed through the Google Play Store.