Cerberus Privacy Policy

Effective date: July 10, 2026
Last updated: July 10, 2026
Product: Cerberus Parental Control System (“Cerberus,” “we,” “us,” or “our”)
Apps: Cerberus Parent and Cerberus Child

Developer: Darius Paul Bacate
Support Email: getcerberusapp@gmail.com
Website: https://cerberus-website-nine.vercel.app/
Privacy Contact: getcerberusapp@gmail.com

This Privacy Policy describes how Cerberus collects, uses, stores, and shares information when you use Cerberus Parent, Cerberus Child, and the Cerberus backend service hosted on Railway. It reflects the current software implementation. It does not claim features that are not present in the product.

Cerberus is a parental-control system. A parent account manages one or more paired child devices. The Child app enforces app-blocking rules set by the parent.

1. Introduction

Cerberus helps parents supervise app use on a child’s Android phone. The Parent app is a dashboard for account management, pairing, app rules, screen-time summaries, and activity events. The Child app pairs to a parent account, syncs installed apps and usage, and blocks apps the parent has limited.

By creating a parent account, pairing a child device, or using either app, you agree to this Privacy Policy. If you do not agree, do not use Cerberus.

Cerberus is intended for use by parents or legal guardians. Child devices are supervised under the parent’s account and direction.

2. Information We Collect

Cerberus collects only information needed to operate parental controls. We do not collect browsing history, SMS content, call logs, contacts, microphone audio, camera photos (except optional parent avatar URLs), or precise location.

2.1 Parent account information

When a parent registers or signs in, we may collect:

Facebook accounts that do not return an email receive a placeholder email of the form facebook_{id}@facebook.signin.cerberus so the account can be created without linking to an unrelated email address.

2.2 Child device information

When a child phone is paired, the Child app sends and we store:

2.3 Installed apps and blocking rules

2.4 App activity and screen time

System UI, launchers, keyboards, and the Cerberus Child app itself are filtered out of activity logging where implemented.

2.5 Protection alerts and access requests

2.6 Information processed only for authentication with third parties

During Google or Facebook sign-in, Cerberus sends the provider token to Google or Facebook to verify identity. Cerberus does not store the Google or Facebook access/ID tokens in the database after verification. Profile fields returned by the provider (email, name, avatar URL, social ID) may be stored as described above.

2.7 Information we do not collect

Based on the current apps and backend:

• Precise or approximate location for parental tracking
• Contacts, SMS, call logs, or calendar
• Microphone or camera capture for monitoring
• Full screen content, keystrokes, or Accessibility window text
• Advertising identifiers for ads
• Analytics SDKs (no Firebase Analytics, Crashlytics, Sentry, Amplitude, Mixpanel, or ad networks in the apps or backend)

ParentApp recommendation-click events may be queued locally on the parent phone for development purposes and are not sent to the Cerberus backend in the current implementation.

3. How Information Is Used

We use collected information to:

1. Create and authenticate parent accounts (email/password, Google, or Facebook).
2. Pair child devices to a parent account and issue device session tokens.
3. Sync installed apps, blocking rules, usage summaries, and activity events between Child app, backend, and Parent app.
4. Enforce app blocking on the child device.
5. Show parents device status, protection integrity, alerts, and (where used) access requests.
6. Allow parents to rename devices, update app policies, unlink devices, approve protection removal, and manage sessions (refresh/logout).
7. Secure the service (rate limiting, token rotation, integrity checks).

We do not use Cerberus data for advertising, selling personal information, or building marketing profiles.

4. Device Permissions

4.1 Cerberus Parent (Android)

The Parent app declares:

The Parent app does not request camera, location, contacts, SMS, microphone, or usage-stats permissions.

4.2 Cerberus Child (Android)

The Child app declares and uses:

5. Accessibility Service

Cerberus Child uses an Android Accessibility Service (AppBlockerService) solely for parental app blocking.

What it does:

• Listens for window-state-changed events.
• Reads the foreground app package name.
• Compares that package to the parent’s blocked-app list.
• If blocked, shows a block overlay / block screen and returns the user to the home screen.
• May report an activity event (package_name, app_name, was_blocked) to the backend when configured.

What it does not do:

• Does not read on-screen text, passwords, messages, or form contents.
• Does not record the screen.
• Is not used for advertising, analytics, or unrelated surveillance.

Without Accessibility Service, Cerberus Child cannot reliably detect which app is in the foreground and therefore cannot enforce parent-configured app blocking.

See also: ACCESSIBILITY_DECLARATION.md in this folder.

6. Device Pairing

Pairing works as follows:

1. The parent generates a short-lived pairing code in Cerberus Parent (authenticated).
2. The code is entered in Cerberus Child.
3. The Child app sends the code and device identity to the backend.
4. On success, the backend issues a device JWT stored on the child phone and links the device to the parent account.

Pairing codes are temporary, single-use, and expire after a short period (approximately five minutes). Cross-family pairing of a device already linked to another parent is rejected. Same-family reconnect is supported using the device hardware identifier.

After pairing, the Child app periodically syncs configuration, installed apps, usage, and integrity status while the device remains paired.

7. App Blocking

Parents set allow/block rules per app package in Cerberus Parent. Rules are stored on the Cerberus backend and synced to the Child app.

On the child device:

• Blocked package names are cached locally so blocking can continue offline.
• Accessibility Service enforces the block when a blocked app comes to the foreground.
• Device Admin is used as a removal guard (not to wipe the device or change the lock screen password in the current implementation).

Parents can view installed apps, toggle allow/block, and review related activity and usage in the Parent app.

8. Authentication

Parent authentication

• Email and password (password hashed with bcrypt).
• Google Sign-In (ID token verified server-side).
• Facebook Login (access token verified via Facebook Graph API).

Parent sessions use short-lived access JWTs and rotatable refresh tokens (hashed at rest). Logout revokes refresh tokens. Reuse of a revoked refresh token causes all of that parent’s refresh sessions to be revoked.

Child / device authentication

• After pairing, the Child app uses a device JWT for API calls.
• Device tokens are not stored in the database; validity depends on JWT signature/expiry and the device remaining paired.
• Unlinking a device from the Parent app removes the device record and related child-device data subject to database cascade rules.

Credentials on the child device

For protection-removal authorization, the Child app may send the parent email and password to the backend for verification. Those credentials are not stored on the child device. Social-login parents use parent-app approval instead of password entry on the child device.

9. Data Sharing

9.1 Sharing with the other app in the family

• The Parent app receives child device metadata, installed apps, usage, activity logs, alerts, and access requests for devices the parent owns.
• The Child app receives blocking policy and limited parent display fields from device config, including parent email, parent display name, and parent profile image URL, so the child can see which parent account the phone is linked to.

9.2 Service providers

We do not sell personal information. We do not share child usage or activity data with advertisers or analytics companies.

9.3 Legal requirements

We may disclose information if required by law, valid legal process, or to protect the safety, rights, or integrity of users or the service, to the extent we are legally compelled and able to do so.

10. Data Retention

If you need account deletion beyond device unlink, contact getcerberusapp@gmail.com (Privacy Contact). We will process reasonable deletion requests manually until an in-app account deletion flow is available.

11. Data Security

Cerberus implements technical measures appropriate to a parental-control backend, including:

• HTTPS for production API traffic (TLS terminated on Railway).
• Optional MySQL TLS for database connections when configured.
• bcrypt password hashing; hashed refresh tokens; signed JWTs.
• Role-based access (PARENT vs DEVICE) and parent-device ownership checks.
• Rate limiting on authentication, pairing, sync, and policy endpoints.
• Security headers (Helmet) and production CORS restrictions for browser clients.
• Device Admin and Accessibility integrity reporting to help parents detect weakened protection.

No method of transmission or storage is 100% secure. Parents should protect their account credentials and physical access to child devices.

Application-level field encryption of database columns is not implemented; data at rest relies on the hosting provider’s infrastructure controls plus the measures above.

12. Children's Privacy

Cerberus is designed for parents/guardians to supervise a child’s device.

• Parent accounts are for adults.
• Data about a child’s device use (apps, usage minutes, open/block events) is collected under the parent’s direction after pairing and is shown to that parent.
• We do not knowingly allow a child to create an independent parent account.
• We do not use child device data for advertising.

If you believe a child has provided parent-account credentials without authorization, contact getcerberusapp@gmail.com.

13. User Rights

Depending on your jurisdiction, you may have rights to access, correct, or delete personal data, or to object to certain processing.

In the current apps you can:

• View and update certain profile fields returned by authentication.
• Revert a custom avatar (Parent app / API).
• Unlink child devices (deletes associated device-linked records as implemented).
• Sign out and revoke refresh sessions.
• Disable Accessibility Service or Device Admin on the child device (which weakens or stops protection and may generate parent alerts).

Not yet available in-app:

• Full parent account self-service deletion.
• Password reset / forgot-password flow.
• Automated data-export download.

To exercise rights not available in the UI, email getcerberusapp@gmail.com with the parent account email and a description of your request.

14. Changes to this Policy

We may update this Privacy Policy when the product changes. Material updates will be reflected by revising the “Last updated” date and, where appropriate, notifying users through the apps or Website https://cerberus-website-nine.vercel.app/. Continued use after an update constitutes acceptance of the revised policy where permitted by law.

15. Contact Information

Developer: Darius Paul Bacate
Support Email: getcerberusapp@gmail.com
Privacy Contact: getcerberusapp@gmail.com
Website: https://cerberus-website-nine.vercel.app/

For privacy questions, data requests, or Accessibility Service concerns, contact the Privacy Contact above.