Core Privacy & Data Invariants Timer schedules and preferences are stored locally in private application storage. Does not harvest personal identification, contact details, or GPS location data. App Limits screen blur processes active apps 100% locally on device without remote logging. Support and privacy inquiries managed directly at support@cibru.in. Privacy Policy - Focus Timer
# Privacy Policy
Last updated: October 20, 2026
**Focus Timer** (Android package **com.focustimer.app**) is provided by **CIBRU, a sole proprietorship owned and operated by Krishna moni Borah**. For privacy questions, complaints, or data requests, contact support@cibru.in. Postal address: Kakojan, Jorhat, Assam - 785107, India. This policy describes the Android App; a website hosting these pages may have separate website privacy information.
Focus Timer provides timers, stopwatches, screen-time summaries, app limits, optional scrolling counters, and Screen Blur overlays. Core timer and app-usage processing takes place on your device. Advertising, purchase verification, optional referral rewards, support, and eligible Android backups involve the external processing described below. No separate CIBRU login or email registration is required to use timers or buy a subscription. Enabling rewards creates a pseudonymous service identity; associated identifiers may still be personal data.
## 1. Device features and permissions
Feature or permissionPurpose and handling
Timers, stopwatches, and preferencesPresets, settings, timer state, and themes are processed and stored locally. We do not upload timer records to the purchase or referral service.
Usage access and app selectionOptional `android.permission.PACKAGE_USAGE_STATS` access reads Android usage events and statistics to calculate screen-time summaries, trends, and app limits locally. Historical charts are calculated from Android's system records; app names and icons are cached in memory. Launcher queries supply app names and icons for selection. Selected package names, limits, daily usage, scroll counters, and snooze state are stored in app-private DataStore; daily counters roll over on a new local day. The App does not upload these records or its installed-app list to CIBRU or attach them to ad requests.
Accessibility: Shorts, Reels, and feed countersThe optional service is protected by `android.permission.BIND_ACCESSIBILITY_SERVICE` and requires you to enable it in Android settings. Android permits it to retrieve window content and delivers scroll/window events. For monitored apps, the implementation examines package/class names, view resource IDs, scroll movement and item indexes, and event **content descriptions** in memory to distinguish short videos from posts and utility screens. Content descriptions can contain text supplied by another app. They are not stored or transmitted; only local per-app aggregate counters are saved. The service does not record keystrokes, screenshots, audio, video streams, or message histories, and does not automate taps or gestures. Counting may be approximate.
Display over other apps`android.permission.SYSTEM_ALERT_WINDOW` allows optional timer stickers, Screen Blur, and limit overlays. The overlay uses Android window effects or a dimming layer, not screenshot capture. It handles interactions with its own controls; accessibility event handling is described separately above.
Local background timing and alerts`android.permission.FOREGROUND_SERVICE` and `android.permission.FOREGROUND_SERVICE_SPECIAL_USE` support ongoing timers and usage monitoring. `android.permission.WAKE_LOCK` helps timing continue during sleep. `android.permission.POST_NOTIFICATIONS`, `android.permission.VIBRATE`, and `android.permission.USE_EXACT_ALARM` support local alerts. `android.permission.SCHEDULE_EXACT_ALARM` is declared only through Android 12L (API 32). Alarm sounds are playback, not recording. No CIBRU push server is used.
Network and SDK permissions`android.permission.INTERNET` and SDK-added `android.permission.ACCESS_NETWORK_STATE` support the online services below. Google SDKs add `com.android.vending.BILLING` and `com.google.android.finsky.permission.BIND_GET_INSTALL_REFERRER_SERVICE` for purchases and attribution.
Advertising identifiers and Privacy SandboxThe merged app includes `com.google.android.gms.permission.AD_ID`, `android.permission.ACCESS_ADSERVICES_AD_ID`, `android.permission.ACCESS_ADSERVICES_ATTRIBUTION`, and `android.permission.ACCESS_ADSERVICES_TOPICS`. Google Mobile Ads may use these for identifiers, attribution, and advertising topics where supported and permitted. These are separate from our locally computed app-usage and scroll data.
SDK component protection`com.focustimer.app.DYNAMIC_RECEIVER_NOT_EXPORTED_PERMISSION` is an app-signature-level AndroidX receiver protection. SDK service and receiver declarations also require their callers to hold `android.permission.BIND_JOB_SERVICE` or `android.permission.DUMP`. These protect components used for background jobs and diagnostics; they do not grant the App permission to read personal content.
You can revoke accessibility, usage access, overlay, or notification permissions in Android settings. Related features may stop working. This build does not request microphone/audio-recording, camera, Bluetooth, contacts, calendar, precise-location, shared-storage, or media-reading permissions. It does not import your files or transmit audio streams. Third-party ad clicks can open other apps under their own controls; an SDK query for a calendar or dialer app is not permission to read your calendar or calls.
## 2. Google Play subscriptions and verification
Google Play handles checkout and payment credentials. CIBRU does not receive your full payment-card number, banking credentials, or Google password. Google Play uses your Play Store account for purchases and restoration; no separate CIBRU account is required.
The App receives purchase tokens, product identifiers, purchase state, and available order information from Google Play Billing. For verification or deletion it sends the app/package identifier, product identifier, actual purchase token, action, request identifier, and a Google Play Integrity token to CIBRU’s configured backend hosted on Supabase over HTTPS. These requests support payment verification, Premium access, replay and fraud checks, restoration, and deletion. The App's request body does not include the locally cached order number, a referral login, Android ID, timer records, or app-usage history.
Verification requires the actual purchase token, not only its hash. The client retains known tokens, product and available order information, plus the status, expiry, and server verification time returned by the configured service. Request identifiers and SHA-256 request hashes bind the requested operation to a Play Integrity proof; a hash alone is not proof of ownership. The service must validate the purchase with Google Play. Online verification is unavailable when backend configuration is missing; preview builds do not send purchases to a substitute service.
The device authenticates its paid-entitlement cache using an installation-scoped Android Keystore HMAC. A random local cache-namespace identifier binds this cache and is not sent as a purchase identity. Access lasts at most 72 hours after verification and never beyond verified expiry, using elapsed time rather than an adjustable wall clock. Reboot, a missing key, or an invalid cache requires online verification. The tag does not encrypt purchase tokens and is not a guarantee against a compromised device. Purchase state and credentials are excluded from configured Android backups and device transfer.
## 3. Optional referral rewards
Rewards are disabled by default. Tapping *Enable Referral Sync* enables online processing to attribute eligible installations, prevent repeated claims, calculate milestone rewards, and verify access. Opening the referral screen alone does not enable sync. Free tools and purchases can be used without joining.
- **Pseudonymous service identity:** Supabase authentication creates a random user identifier and session credentials without asking for a name, email, password, or phone number. This is an online identity even though you do not complete a conventional sign-up form.
- **Device identifier:** During referral installation registration, the App reads Android ID locally and computes an app-scoped **SHA-256 device hash**. It sends that hash, not the raw Android ID, IMEI, MAC address, or hardware serial number. The referral service contract derives a further app-scoped, server-keyed HMAC for duplicate detection and stores that second hash in its database. These stable identifiers are **pseudonymous, not anonymous**; hashing does not remove all linkability.
- **Attribution:** The App caches the full Google Play Install Referrer value and Play's server-provided installation and referral-click timestamps locally, then sends them with the app identifier, request identifier, device hash, and Play Integrity token to the registration service using the referral session. The raw referrer can contain referral or campaign parameters. These are processed to validate the installation and referral. Later status and deletion requests use the session and app identifier; they do not resend the device hash or full referrer. Google processes integrity checks under its own terms and privacy policy.
- **Progress and rewards:** The service stores the app-specific profile, referral code, eligibility, installation association, credited referral count, referral events, awarded milestones, and reward expiry. Shared links contain your referral code, visible to recipients. It is not a password or proof of ownership.
Invitations qualify only after eligible installation, referral opt-in, and verification. See reward terms for milestones. The device caches verified referral access for at most 24 hours after successful sync and never beyond reward expiry. Rebooting the device requires revalidation; simply reopening the App can reuse a still-valid cache and attempts a refresh when sync is enabled. Clearing storage, reinstalling, or changing devices may lose access to a pseudonymous profile.
On the *Get Free Premium* screen, *Turn off sync* (shown as *Clear local referral data* when already off), or the exact `focustimer://referral/unsync` link, stops automatic syncing, removes local referral access, and clears cached code, count, entitlement, and attribution. Minimal registration ownership and the session are retained for an explicit restore of sync or a deletion request. This does not delete the server profile or pause reward expiry. Only *Enable Referral Sync* resumes automatic referral work. Use *Delete referral data* for server deletion. Check any storage-error message: an unsaved opt-out is only effective in the current process. A separately valid paid subscription continues independently.
## 4. Advertising and consent
The free tier uses Google Mobile Ads (AdMob), including banner, interstitial, and rewarded advertising. Google and its partners may collect or receive IP addresses, advertising and other device/account identifiers, device information, app/ad interactions, and diagnostics. IP addresses may estimate approximate location. These data support ad delivery, measurement, personalization where permitted, security, and fraud prevention. The App does not request precise GPS location. This SDK processing is separate from the timer, app-usage, and accessibility records that the App processes locally.
The App checks advertising consent through Google’s User Messaging Platform and presents a form when required. Where available, reopen *Settings > Privacy & Cookie Settings* to change choices. Android settings also provide advertising-ID controls. Availability of personalized or other ads depends on region and consent requirements. Verified paid or referral Premium suppresses in-app ads; it does not erase information previously processed by advertising providers. Consent-status requests still run, and Mobile Ads may initialize when consent settings permit, including for Premium users. Premium is not a switch that disables every Google SDK or network request.
See Google’s Privacy Policy, Google’s use of information from partner apps, and Google Mobile Ads data disclosures.
## 5. Support, service providers, and purposes
If you email support, we process your email address, message, and receipts, diagnostics, or other information you choose to provide to answer your request. We may request limited ownership evidence for purchase or deletion requests. Do not send passwords, sign-in codes, full card details, or raw purchase or authentication tokens.
Google Play Billing handles purchase tokens and transaction state; Google Mobile Ads (AdMob) handles advertising data; User Messaging Platform handles consent choices; Play Install Referrer handles invite attribution and install/click times; and Play Integrity handles app/device/licensing verification. Supabase provides backend hosting, database, and pseudonymous referral authentication. The Android app calls Supabase using OkHttp HTTPS requests, not a Supabase database SDK. Providers may process IP addresses, request times, and operational/security logs. Support and infrastructure providers process information needed to operate the service, and data may be disclosed when legally required.
Online legal links open a browser or an in-app WebView. The hosting provider receives ordinary web-request metadata and may use website storage under its website policy. Sharing an invite uses Android's share sheet; the app you choose receives the link and referral code. Focus Timer does not read your contacts to send invitations.
Where a legal basis is required, we process data to provide requested services, pursue legitimate interests in security, fraud prevention and support where permitted, comply with legal obligations, and on consent where required, including optional referral participation and applicable advertising choices. You can withdraw consent without affecting the lawfulness of prior processing.
Providers may process data outside your country. Applicable transfer protections depend on the provider, destination, and legal requirements. Contact us for information about arrangements relevant to your data. We do not promise that all online data stays in your country.
## 6. Local storage, backups, and security
Local settings and caches use Android app-private DataStore files and SharedPreferences. The core features have no separate whole-database-reset control. SDKs can also keep their own app-private files or databases. Timer and theme settings may be included in Android cloud backup or device transfer when enabled. App-usage-limit data, referral attribution and session state, and purchase verification state are excluded by the App’s backup rules. Google manages Android backup retention and deletion through its account and device controls.
We use HTTPS for backend communication, Android app isolation, request verification, and restricted backend access. No storage or transmission method is completely secure. Pseudonymous identifiers and hashes remain subject to data-protection safeguards.
## 7. Retention and deletion
- **Local records:** Retained until replaced, deleted in the App, cleared through Android storage settings, or removed by uninstalling. *Clear cache* removes temporary cached files, not the App's persistent preferences. *Clear storage* removes app-private data, including preferences and databases; it does not erase Android's system UsageStats history. Backups are managed separately. Complete any in-app server-deletion requests before clearing storage or uninstalling, because those actions remove the session and purchase tokens needed for retries. They do not delete backend records or cancel subscriptions, and they remove this installation's saved sync-pause preferences.
- **Purchase records:** Known tokens and verification state are kept to maintain access and permit deletion retries. The configured backend may retain purchase-token hashes, deletion markers, billing-event records, and legally required records for anti-replay, billing, and security purposes. Ask support which records and retention periods apply to your request; the Android client cannot inspect or guarantee the backend's cleanup schedule.
- **Purchase deletion:** Use *Settings > Delete purchase verification data* or the Premium screen. This pauses automatic device sync, clears local paid access, attempts to remove the entitlement cache/key, and rejects older verification callbacks. It requests deletion for known tokens only after the pause is saved and the key is removed. With no token, sync still pauses but remote deletion cannot be confirmed. Failed requests may retain token/product pairs for retry; the pause flag and random local cache-namespace identifier remain. Only an explicit *Restore Purchases* (also labeled *Sync Subscription* while subscribed) resumes syncing. A purchase tap or app restart does not. Check storage, key-removal, and service errors; a pause that could not be saved is only effective for the current process.
- **Referral records:** The profile, installation associations, progress, and events remain until a verified deletion request is completed. Opt-out or reward expiry does not delete the remote profile. Under the referral service contract, deletion removes the app-specific profile, its installation records and rewards, linked referral events, request receipts, and rate-limit records; it unlinks other installations that referred to that profile. Other participants' profiles remain, and their previously awarded aggregate counts and reward expiry are not recalculated. An app-scoped device HMAC and deletion metadata remain for 90 days to prevent repeat claims. Otherwise, short-lived request receipts expire after ten minutes and rate-limit records become eligible for cleanup after one day. Cleanup depends on scheduled maintenance. After confirmed remote deletion, the client clears referral preferences and its stored session; a local storage failure is reported separately.
- **Shared authentication:** App-specific referral deletion does not automatically delete the shared service authentication identity or another CIBRU app’s records. Request deletion of the associated identity or wider data explicitly through support so we can review scope and lawful retention.
- **Support and provider records:** Correspondence is kept as needed to handle and document requests and meet legal obligations. Providers’ operational logs and backups follow their retention arrangements. You may request deletion of support information, subject to lawful retention.
Cleanup removes eligible records when scheduled maintenance successfully runs, rather than at an exact promised hour. A lost session may prevent in-app deletion of an older pseudonymous profile. If no referral session or registration marker is present, the App can complete local cleanup without contacting the service; this does not confirm deletion of an earlier installation's profile. For local clearing instructions, see Data Deletion. For server scope, verification requirements, and an email route usable without the App, see Referral & Purchase Data Deletion.
**Deletion does not cancel Google Play billing.** Cancel separately in Google Play subscriptions. Purchase and referral deletion are separate; a valid independent entitlement can continue.
## 8. Your privacy rights
Depending on applicable law, you may request access, correction, deletion, or a copy of your data, object to or restrict processing, withdraw consent, and complain to your local data-protection authority. Contact support@cibru.in, identifying Focus Timer and the data concerned. We may need limited verification and enough information to locate a pseudonymous record. We respond within applicable legal deadlines and explain lawful exceptions.
For EEA and UK users, rights may include portability and objection to processing based on legitimate interests. Managing local storage alone does not delete backend records. For California users, CIBRU does not sell personal information for money; advertising providers’ use or disclosure of identifiers and activity for cross-context behavioral advertising may constitute “sharing” under applicable law. Use available advertising choices and contact us about applicable opt-out requests. We do not deny statutory rights because you submit a privacy request.
## 9. Children
Focus Timer is a general-audience productivity utility intended for users aged 13 or older, or the higher minimum age required by local law. It is not directed to children below that age. Do not use optional online features without legally required guardian authorization. If you believe a child has provided information improperly, contact us so we can investigate and delete it where required.
## 10. Changes and contact
We will post changes with an updated date and provide additional notice or seek consent where required. Operator: CIBRU, a sole proprietorship owned and operated by Krishna moni Borah. Privacy, subscription, referral, and support requests: support@cibru.in.
© 2026 CIBRU. Focus Timer. All rights reserved. • Legal Home • Terms of Service • Subscription & Refund Policy • Referral & Purchase Data Deletion • Contact: support@cibru.in