Privacy Policy

Introduction

Earn to Play ("we," "our," or "us") is committed to protecting the privacy of children and families who use our parental control application and web portals. This Privacy Policy explains how we collect, use, disclose, and safeguard information when you use those mobile and web surfaces.

Data controller and service operator: Trukhnova Olha, Avenida Alas Clarín 16, 4.º Izq., 33404 Avilés, Spain. Phone: +34 671 918 928. Email for privacy and support requests: v.trukhnov@gmail.com. Earn to Play is operated by the individual named above; this policy does not represent Earn to Play as a separately incorporated company.

Information We Collect

Information Provided by Parents/Guardians

• Account Information: Email address and password for parent account creation
• Child Profiles: Child's display name or nickname, age or age-related profile setting, and avatar selection. Parents are encouraged to avoid entering real child names.
• Safety Contact Information: Optional emergency phone details used for device-blocking safety flows may be stored with family/child settings until the final retention/minimization policy is approved.
• Parent Media and Voice Input: Parent-selected child avatar photos can be stored locally on the parent device, and parent AI-helper voice input may use microphone/speech recognition permissions when enabled.
• Device Information: Device identifiers necessary for app functionality

Information Collected Automatically

• App Usage Data: Screen time statistics, quest completion records, installed-app inventory, package visibility metadata, overlay/foreground monitoring state, and app-usage metadata used for controlled-app selection and monitoring. This can include package names, app display names/categories, current or foreground app/session state, app icon metadata, boot/restart or battery-optimization status, and emergency phone/call-screening state where Android safety flows are enabled.
• Technical Data: App version, operating system, functional notification data, Cloud Functions operational logs, and crash diagnostics handled through Firebase Crashlytics
• Support Diagnostics: On Android, if a parent or child manually exports support logs, the app may create a local shareable diagnostic file with recent app/device logs, app version/platform info, and monitoring, accessibility, wallet, or timer context. iOS currently has visible support-export UI paths, but native log collection/channel coverage and QA are not final. The export applies redaction, but sanitizer coverage and support-export QA are not final; exported logs may still contain device, app-usage, or identifier context. They are not sent to us unless shared through the support process.

Web Portal Authentication and Security

The child web portal uses a temporary eight-character code created by a parent. The maintained browser client keeps the parent password and child login code in memory, uses Firebase Authentication with browser-session persistence, and stores the child profile id, family id, and display name in sessionStorage while the child session is active. A separate PII-free session lease stores only version/status and activity timestamps so expired sessions are not restored. The child portal does not accept child photo, audio, or video submissions.

Firebase App Check with reCAPTCHA Enterprise is configured for web anti-abuse protection. Google may process browser, IP, device, and integrity signals and may use cookies or similar browser storage needed for that security purpose. Maintained portal source does not initialize advertising or analytics trackers. The current UI signs the parent portal out after 15 minutes of inactivity and the child portal after 30 minutes, and both browser leases have an eight-hour absolute limit; deployment and production behavior must still be verified before launch.

Information Not Cloud-Stored in Child Mode

For current tracked child photo proof flows, media is not uploaded to Firebase Storage; Firestore stores review metadata and local path references. Kid-side video capture/storage metadata is partial; parent video review/player support, audio reachability, and cleanup behavior remain under verification.

• Advertising identifiers (IDFA, AAID)
• Precise location data
• Address book/contact-list data
• Cloud-stored personal photos
• Cloud-stored voice/audio recordings
• Cloud-stored video recordings

How We Use Information

We use collected information to provide, protect, debug, and support the service, including to:

• Provide parental control and screen time management features
• Display quest completion status to parents
• Sync data between parent and child devices
• Support optional parent AI draft flows where enabled (see AI Services section)
• Improve app performance and fix bugs
• Respond to support requests
• Protect accounts, enforce security controls, prevent abuse, and operate diagnostics/logging needed for reliability

Data Storage and Security

Local Storage

Current tracked child media files are intended to stay on the child device and are not uploaded to our servers. Firestore stores review metadata and local path references. Audio/video reachability, parent review support, and final cleanup behavior remain under verification across devices.

Website Cookies and Browser Storage

The maintained web portals are designed without optional advertising or analytics cookies. Strictly necessary Firebase Authentication, App Check/reCAPTCHA security, and sessionStorage mechanisms may operate so users can sign in and the service can prevent abuse. If optional analytics or marketing technologies are added later, they must remain disabled until the required choice and consent controls are implemented.

Cloud Data Services

We use Firebase/Google Cloud services. Firebase service locations must be verified in the selected project before launch; Functions are configured for europe-west1.

• Parent account information
• Child profile metadata such as display name or nickname, age or age-related profile setting, and avatar selection. Parents are encouraged to avoid entering real child names.
• Quest definitions and completion records
• Screen time balances and rules
• Activity history (app usage statistics; retention depends on the data set and cleanup coverage)

Security Measures

• App/Firebase traffic is expected to use HTTPS/TLS; website Hosting SSL/HSTS/security headers remain pending until Firebase Hosting configuration and domain verification are complete
• Firebase Security Rules restrict data access
• Parent PIN required for settings access
• Security review process before public launch

Third-Party Services

We use, or may use where a planned feature is implemented and approved, the following third-party services:

• Firebase (Google): Authentication, Firestore, Realtime Database link-code status, cloud functions, App Check/Play Integrity, Cloud Messaging notifications, Cloud Functions operational logs, and Crashlytics diagnostics. Visible notification text avoids child names, but low-balance notifications can reveal a child wallet/status category; FCM transport payloads can include family/child identifiers and balance until the launch payload, retention, and minimization contract is finalized. App Check and Play Integrity use app/device integrity signals and debug App Check tokens may exist in debug/local flows. Cloud Functions logs may contain family/child/member identifiers, package/app metadata, link-code or token status, wallet/balance values, AI request/response metadata, and operational error metadata; some paths apply redaction/minimization, but broader logging remains a launch verification item. Crashlytics stack-trace handling, custom-key allowlisting, user identifier policy, and retention settings remain launch verification items.
• Website fonts: Public website pages load the Quicksand font from this website. They do not request fonts from Google Fonts.
• Apple iOS device-management APIs: Planned iOS support, subject to implementation and Apple entitlement approval
• Android monitoring and safety APIs: UsageStats, Accessibility, package visibility, overlay/foreground service, reboot persistence, battery-optimization, phone/call state, and call-screening permissions used for Android monitoring, blocking, and emergency-call safety flows where enabled
• Google Gemini AI: Where enabled, parent AI draft flows may use Gemini to propose quest drafts for parent review (see AI Services below)

Current source is intended to avoid advertising networks and marketing trackers in the child interface. Crash diagnostics and functional data handling are disclosed here and must be verified before public launch.

AI Services

Where enabled, parent AI draft flows may use Google Gemini to propose quest drafts for parent review. Provider retention/logging, consent recovery, ownership tests, and launch readiness remain pending. Important details about our AI usage:

• What we send: Parent prompts, recent AI chat context, and covered child context such as child aliases/profile settings, age group, development focus areas, preferred difficulty, weekly progress summary, quest category, reward constraints, monthly activity summaries, and top app package/time statistics when AI recommendations are used. Current AI chat should include only child context covered by consent and passed for the current request. Monthly recommendations currently accept client-provided child activity summary fields, validate and bound them server-side, and then send the sanitized summary, including top app package identifiers and time counts, after access/consent checks. Real child identifiers are used server-side for authentication, consent, and plan ownership checks; Gemini prompts are intended to use aliases where current prompt builders support it.
• What we receive: AI-generated quest suggestions and educational activity drafts for parent review
• Provider retention: Gemini retention, logging, and training restrictions depend on the configured Google AI service tier and settings; this must be verified before public launch
• No child media by design: Current parent AI draft flows are not designed to send child media files to AI services; this must remain covered by launch verification
• Identifier handling: The app attempts to replace known child names with aliases before AI calls, but user-entered text may still contain personal data. Full PII/DLP anonymization and provider logging/retention settings remain launch blockers.

Where enabled and supported by the current flow, AI drafts are shown to parents for review. Provider retention/logging and recurring schedule activation remain pre-launch verification items.

Parental Rights and Controls

Parents/guardians have the right to:

• Access: Request access to stored family-account data by emailing v.trukhnov@gmail.com; the complete automated export workflow is still being implemented
• Modify: Update or correct any child profile information
• Delete: Request deletion of family data by emailing v.trukhnov@gmail.com. A complete erasure workflow is still being implemented; requests remain subject to legal obligations and the currently available backend capabilities.
• Export: Request a copy of stored account data by emailing v.trukhnov@gmail.com. Export remains support-handled before launch; exact scope and process are launch legal/product requirements.
• Consent Withdrawal: Use the withdrawal control where available or email v.trukhnov@gmail.com until the complete workflow is implemented

Data Retention

• Account Data: Deletion requests are handled through v.trukhnov@gmail.com and currently available backend capabilities. Some account, history, audit, billing, or legal records may remain until the complete erasure workflow and final retention policy are implemented and approved.
• Quest Completion Data: Retention depends on the exact Firestore collection and cleanup function coverage; broad deletion/export scope is still being implemented
• Activity History: Raw event, hourly aggregation, and daily-summary retention are tracked separately and must be verified against the deployed cleanup jobs before launch
• Local Media Files: Current tracked child media is intended to stay local; Firestore stores metadata/path references, and cleanup after review is still under device-flow verification
• FCM Notifications: Parent notification tokens and transport payload metadata need a finalized retention and minimization policy before launch
• Crash Reports: Handled through Firebase Crashlytics diagnostics; custom keys, logs, user identifier policy, and retention/anonymization settings must be verified before public launch
• Operational and Support Logs: Cloud Functions operational logs and manually exported support diagnostics need finalized minimization, retention, and support-sharing policy before launch

Children's Privacy (COPPA-oriented Controls)

The closed beta uses the COPPA-oriented controls described below. These controls have not been represented as independently certified. Before any public or global launch, the consent method, deletion/export workflow, provider settings, retention practices, and store-policy requirements must be reviewed.

• Parent account setup and core child-data consent are required before child access is enabled. AI features require separate consent.
• Parents can review child information and request deletion while the complete erasure workflow is being implemented
• We aim to minimize collection and process data needed for current app functionality, security, diagnostics, and support as described in this policy; final retention and minimization review remains pending
• Current source is intended to avoid child-mode behavioral advertising and marketing trackers; release-binary and store-policy verification remain required
• No intentional sharing of children's data with third parties for marketing; final provider settings and launch verification remain required

Verifiable Parental Consent

For the closed beta, the adult setup flow requires the adult to confirm parent or legal-guardian authority, acknowledge the child-data notice, and complete a separate email confirmation before child access is enabled. Before public or global launch, this method must be reviewed against the jurisdictions in which the Service will be offered and strengthened where required.

• Parent creates an account using their email address
• A separate confirmation email must be completed before child access is enabled
• Parent must acknowledge and accept our Privacy Policy and Terms of Service
• Parent creates a PIN for accessing parental controls
• Consent withdrawal and deletion requests are handled through available portal/backend controls or v.trukhnov@gmail.com until the complete erasure workflow is implemented

Data Breach Notification

In the event of a data breach that affects personal information:

• Incident-response and breach-notification processes are being prepared before public launch
• Final user or supervisory-authority notices will follow the approved process and applicable legal requirements
• Security-review and escalation ownership must be approved before public launch

International Data Transfers

For users outside the European Economic Area (EEA), data processing locations depend on the selected Firebase/Google Cloud services and must be verified before launch. Functions are configured for europe-west1.

Changes to This Policy

We may update this Privacy Policy as the closed beta changes. We will show the effective date, provide notice when required, and obtain renewed parental consent before materially different child-data practices begin where required. This policy must be reviewed and re-approved before any public or global launch.