Privacy at Salah Route

On the website, we ask your browser for location when the page opens, unless permission is already denied. You can decline and still browse. If allowed, your browser updates your position on the map, nearby rankings, distances, and travel estimates while the page is open. Compass access, where available, controls the blue heading cone.

You may instead type an address; that search text and a selected place are sent to Google Places for suggestions and coordinates. For travel estimates, the selected coordinates are sent to our server, which asks Apple Maps (its travel time service) or Google Routes. Where a masjid has not posted times, a rounded location (about 5 km) is sent to AlAdhan (aladhan.com) to calculate prayer start times for your area. Loading a map or opening directions may share connection or location data with Google or Apple under their own policies. We never store your location history.

Optional usage sharing and its event transport are disabled in this build, including after you choose to help during setup. That choice records a preference for future use. When enabled separately, our anonymous area and city counters keep daily totals without an account or device ID. We do not store raw IP addresses in our app database. Service providers may process connection data as described below.

If you request the one-time home-masjid route comparison during setup, our server rounds your origin to 0.001 degrees, about 100 metres, before sending it with up to four masjid destinations to the provider for the displayed map. Google maps use Google Routes; Apple maps use Apple Maps. The response is fresh for 15 minutes and its content is removed by daily cleanup after 24 hours. A one-use service marker remains until the guest record is deleted. We do not save the origin or a location history with that marker.

On iPhone, the map uses location and compass readings while open. Optional nearest-masjid reminders and Lock Screen prayer cards can use your last available location, including significant location changes while the app is closed if you separately grant Always access. The latest fix and reminder settings are stored on your device. iOS controls when background updates occur; background location is not tracked continuously.

On Android, the map uses location while open. If you separately enable background updates and grant Always access in phone Settings, passive location changes can update nearby widgets and reminders while the app is closed. Android controls delivery and may delay or stop updates. The latest fix and reminder settings stay in private device storage; schedule and nearest-masjid requests may send the current coordinates to our server. We do not save a movement history. You can turn background updates off at any time.

Prayer cards can display mosque names, times, and a location-update timestamp on your Lock Screen. You can disable them in Settings. iPhone uses Live Activities; Android uses prayer notifications. Android decides whether notifications and widgets appear on the Lock Screen, and you can hide their content in phone Settings. Travel estimates for one selected home or nearest prayer-card option send your latest coordinates to our server and on to Apple Maps or Google Routes, just like map estimates.

Calendar syncing is a separate, optional Google connection, initially limited to the owner pilot. You choose a calendar you own, a masjid, timing, duration and colour. Google grants access to your owned calendar events and calendar names; our application uses it only to manage your prayer blocks. If you enable soft prayer colors, an additional calendar-metadata permission lets us create and maintain their color labels while preserving unrelated calendar settings. It does not invite people or modify your other appointments. These blocks reserve time; they do not record whether you prayed.

We store an encrypted Google connection credential and your settings, a hashed Google account reference, and event identifiers and sync receipts. A browser can share an approximate city only while open. In supported app builds, you may separately link your signed-in app by matching a one-use code and approving the requested permissions. Calendar sign-in and app sign-in remain separate; matching email addresses alone never links them. The app receives a limited, revocable credential rather than your Google or Outlook credential.

If you approve city updates, the app can share its latest accepted, rounded location and observation time for prayer timing. Only the latest approximate city is retained, encrypted, without a movement history. This reuses the app's location updates; it does not start continuous location tracking. Background updates require separate phone permission and are controlled by iOS or Android, so delivery may be delayed or stop. Stale or unavailable updates do not replace your calendar's saved city. You can disconnect a linked phone on the Calendar page or in the app. Revocation stops future authorized updates and clears that phone's stored city. Deleting the app account revokes its linked phone permissions, but the independent Google Calendar connection must still be disconnected separately.

Google receives the block title, time, selected masjid or city and source description. We do not send calendar data to advertising services or product analytics, sell it or use it to train AI models. Our use of information received from Google APIs follows the Google API Services User Data Policy, including its Limited Use requirements.

Changing between a phone calendar writer and a server connection, or replacing the phone's calendar target, can pause new syncing until previously issued blocks finish. This prevents duplicate blocks without deleting your calendar content. A short-lived opaque writer safety receipt remains until the last possible future block or lease ends; it contains no location, login credentials or event contents. After recovery preparation, calendar writing pauses for at least eight days so blocks written after that backup can finish safely.

Disconnect Google Calendar on the Calendar page to stop syncing and remove the connection, settings and sessions. We retry an unavailable Google revocation while syncing stays paused. The blocks already in Google Calendar remain until you remove them there. Sync receipts expire after 30 days; restricted recovery backups can retain deleted records for up to 30 additional days. This independent Calendar connection is not the prayer-history account: deleting your Salah Route account alone does not disconnect it. You can also withdraw its access in your Google account. The owner's one-time migration reads and reconciles only previous automation's marked prayer blocks in the chosen calendar, after backing them up.

The private owner trial can additionally link Microsoft Outlook through Microsoft’s authorization screen. Microsoft grants calendar read/write access; our application manages only its marked prayer blocks in a calendar you own. Its encrypted sign-in credential, settings, hashed account reference and sync receipts are kept separately. Microsoft receives the block title, time, selected masjid or city and source description. Disconnect Outlook to erase its stored credentials and stop future writes; existing blocks remain. Encrypted settings and the hashed account reference remain to prevent a reconnect from silently duplicating your blocks in another calendar. Remove SalahCal’s permission in your Microsoft account to revoke the provider grant too. Disconnecting the trial’s Google account also deletes the linked Outlook connection and subscription links.

Apple Calendar and an optional Outlook subscription can use a private, revocable calendar link. Anyone with that link can read the selected prayer blocks, so keep it private. Your calendar app decides when to refresh it and may not count subscriptions as busy. Disable the link on the Calendar page, and remove the subscription from your calendar app. Subscription tokens and settings are encrypted at rest in our database; no calendar password is collected. Cloudflare, our hosting provider, may retain request URLs containing private subscription links or OAuth callback parameters in its request records. This hosting processing is separate from product analytics.

Supported iPhone app builds also offer direct Apple Calendar syncing. You separately approve prayer-plan access and Apple's Full Calendar Access permission, then choose an account where the app creates one dedicated SalahCal calendar. Full access is needed to find and update the app's own blocks without duplicating them; our integration searches only its registered calendar within its limited upcoming window. Unrelated appointment details stay on your phone and are not uploaded. Private device receipts, excluded from device backup, retain the calendar and event identifiers and an account-specific index so reconnecting can update existing blocks. Stop syncing and sign-out preserve these receipts and existing blocks. Confirmed app-account deletion erases only that account's private receipts, with a retry if device cleanup fails; it leaves Calendar events intact. Remove upcoming blocks removes only the app's marked future blocks. Calendar updates while the app is closed depend on iOS background execution and are not guaranteed to be immediate. No Apple Calendar password is collected.

Usage sharing starts off. Consent version 4 is a new choice: older choices do not carry over. One optional Settings choice covers product behavior, masjid popularity, coarse area trends and daily Tahajjud totals. If you are under 16, ask a parent before turning on usage sharing. These statistics may reveal religious interests.

PostHog is the intended product analytics processor in the United States. Its transport is off in this build. If activated separately, our server would send a persistent random installation ID, random event IDs, event times, platform and allowlisted screen, control and broad notification categories. These events would count app sessions, screen views, control taps, notification and widget opens, Live Activity taps and announcement reads. The installation ID is linked across visits, even though it is separate from your account. It is pseudonymous, not anonymous.

PostHog receives no masjid IDs or names, coordinates, area, search or typed text, emails, support/report content, prayer completion history or per-installation Tahajjud completion. We use no replay, screen recording, automatic capture, advertising tracking or person profiles. Product analytics stays disabled until the owner verifies processor settings and deletion capability. When activated, retention is limited to 12 months.

When optional sharing is enabled separately, our Cloudflare D1 counters can count masjid detail views, chip/card taps, search results opened, directions, drive/walk starts and website taps per masjid per Toronto day. Coarse area counts use 0.25 degree cells, roughly 28 km north to south. Geography and popularity are separate totals. No installation ID, IP, browser headers or time of day is stored with them. Counts are best effort interactions, not attendance or unique people. These counters expire after 730 days, approximately 24 months. CSV exports show counts below five as <5.

Withdrawal clears pending events and stops future optional sharing. Your device retains installation references only so you can request erasure of earlier data. Delete my usage data in Settings pauses sharing and sends each saved installation reference to our server for a PostHog event deletion request. A request awaiting provider approval keeps its reference and sharing stays off. References are discarded only after all requests are accepted for processing; deletion is asynchronous. If the service is unavailable, retry or contact our Privacy Officer. If you already cleared app data, we may be unable to locate pseudonymous events. Aggregate totals contain no per-person reference and cannot be individually erased.

On iPhone, our server can start and update your Lock Screen prayer cards while the app is closed. This is optional. The app asks once with an alert; if you choose Not now, the app's own cards keep working on your phone. No account is needed. If you turn it on, we store a random ID for your phone (not linked to an account), Apple delivery tokens, the masjid your cards follow and when and how you chose it, your home masjid and Friday masjid if you set them, your device time zone, the app build and your card choices (which prayers, how early, clock, style and travel mode). No GPS coordinates, travel estimates or location history are sent for remote cards.

A nearest masjid is used for 12 hours after your phone checks in. After that, cards follow your home masjid if you set one. With no home masjid, the same masjid is shown as a saved area for up to 7 days, and then remote cards wait until you open the app again. A masjid you fix yourself stays your choice.

Apple receives the card content and delivery token through APNs and may show a card-start alert. We keep delivery receipts and app callbacks separately; neither alone proves that a card was visible. Turning remote cards off revokes future sends when the server acknowledges your request. If offline, revocation remains pending. An already accepted push cannot always be retracted; the app ends unwanted cards when it observes them.

Turning Lock Screen cards off stops future sends and deletes your phone's enrollment about a day later; that day lets us end cards already on your Lock Screen. Deleting your account does not remove this enrollment, because it is not linked to your account: turn Lock Screen cards off to remove it. Cards linked to an account during the earlier owner trial are removed when that account is deleted. An invalid Apple token also stops delivery. Tokens are rotated when Apple changes them, and inactive installations are removed after 30 days without an app observation. Per-activity tokens expire with the prayer window; delivery records are retained for at most 30 days. Recovery replays account erasure before any restored records can serve users.

Your favorite masjid, reminder choices, and custom card order are saved on your device. The iPhone app also caches schedules and its latest location for offline reminder details. The Android app keeps a private copy of schedules, your prayer log and the Home screen widget data on your device, and Android's own device backup does not copy it. On Android, your sign-in token is kept in the Android Keystore. You can change permissions in device settings and clear local data by removing the app or site data.

In the app, tapping I've prayed can log that prayer. Each entry holds the date, the prayer, the masjid, the time, and whether you were at the masjid.

For a manual entry, At the masjid normally comes from your location at the moment of the tap. The "Log masjid prayers automatically" setting logs your prayer when you're at a masjid at prayer time. It is on by default. It uses a sustained, accurate visit during a posted congregation time; you can turn it off in Settings or in the Prayer log. These entries are labelled Detected at masjid and can be corrected or removed; location does not prove that you prayed. Background detection requires your separate Always permission and is controlled by iOS or Android, so it may miss visits. Only the masjid, prayer, time and entry source are saved, never the location samples themselves. To tell nearby masjids apart, the iPhone app may send our server a fixed map square of about 1 km that contains you, plus a margin (about 3.8 km across in all, not centred on you), to look up the masjids in it; we do not store that area.

Guest prayer logs stay on your phone in current app builds. Choosing Apple or Google sign-in enables cloud backup (Android offers Google sign-in only) with your consent. We keep an internal account ID and your sign-in provider's identifier to restore your history. We also save your name and, for Google, the link to your Google profile photo, so your account screen can show who is signed in. Apple shares your name only the first time you sign in with Apple; Apple shares no photo. The name and photo link are encrypted and shown to you on your account screen; support sees your name only when you include your account details with feedback, as described below. Your phone loads the photo directly from Google without cookies or a referring page. A separate Salah Route password is not required. Phone verification is an optional service described below. We also request and save the verified email provided by Apple or Google, including an Apple private forwarding address if you choose one, to fill in support forms and send confirmations and replies. This grants no access to your inbox or contacts. You can change or remove the address on each feedback message. Signing in does not subscribe you to announcements or newsletters. Account-linked history and contact information are not anonymous.

You can turn off logging, or backup, at any time in the Prayer log. With backup off, nothing more is sent and your log stays on your phone.

Sign in with the same linked provider on another phone to restore your cloud history. Your phone keeps a small local copy and pending changes for offline use. A change is saved in the cloud only after our server confirms it.

Delete prayer history removes the account's active cloud entries when the server confirms the request. Connected devices clear that history when they next sync; an offline device cannot receive the deletion until it reconnects. Delete account additionally removes the saved sign-in email, split name fields, profile photo link, optional verified phone, signup information, associated guest service records and communication consent events, and revokes sessions. You can do this in account settings or on our account and data page. Signing out alone does not delete your cloud history. If you stop using Sign in with Apple for Salah Route in your Apple ID settings, or delete your Apple Account, Apple notifies us and we delete your whole Salah Route account and its cloud history, including any Google sign-in linked to it. While your account exists, we keep an encrypted disconnection credential from Apple or Google, used only to disconnect that provider when you delete your account. Disconnecting Apple or Google is handled separately and does not hold up deletion of the app account. If that provider is unavailable, an encrypted disconnection credential is retried for up to 30 days, then removed.

Older app versions backed up logs under a hashed random app ID. Those backups alone cannot restore a lost phone. After sign-in, a current app can transfer the history still present on that phone. Existing aggregate reports from older backups show groups of at least five app IDs. Active records are separate from restricted disaster-recovery backups, which expire after 30 days; deleted records must not be reactivated when restoring a backup. We keep restricted deletion markers separately from backups: an internal account ID, operation ID, history generation and, for a single-entry deletion, its date/prayer entry ID and revision. These markers contain no prayer location or sign-in token and are retained to prevent recovery from bringing deleted records back. We also retain minimal sign-in revocation markers: a provider identifier and cutoff time, used to reject old sign-in responses. When a marker comes from an Apple account message, it also keeps that message's event ID. They contain no prayer history. These markers are pseudonymous records, not anonymous data.

We do not sell your prayer log, share it with advertisers, or use it for ads.

On iPhone, you can let Salah Route use Motion & Fitness. It confirms that you walked or drove to a masjid and stayed, so automatic logging skips drive-pasts. It also lets the app ask for your location less often, which saves battery.

Motion data stays on your iPhone. It is never uploaded to our servers. Your prayer log still saves only the masjid, prayer, time and entry source.

This is optional. Without it, the app works the same, and automatic logging uses location only. Turn it off anytime in Settings or in iPhone Settings.

When you use a setup service such as route comparison, phone verification or guest linking, our server creates a random guest ID and secret. Your phone stores the secret in protected device storage; our server stores only its hash. This is a service credential, not an analytics installation record. Creating it does not turn on usage sharing.

For optional sign-in, we store verified provider email and first and last name when the provider supplies those fields. We also record signup platform, build when known, setup step, and coarse country, region and city from trusted network metadata. Signup geography does not come from GPS. We encrypt names and contact details and keep them separate from product analytics. Linking guest setup data to your signed-in account does not merge accounts by email or phone.

Phone verification starts off in this release. If enabled later and you choose to use it, we encrypt the verified phone number and keep a keyed contact hash and verification time. Twilio Verify would process the phone number and verification request to send and check the code. Synthetic test mode is limited to staging or local test numbers and sends no real SMS. Verification codes are not stored. Expired challenges, receipts and cached replies are removed by daily cleanup within 24 hours of their expiry; an approved receipt keeps its own short deadline.

The planned Text me masjid updates (coming soon) checkbox starts ticked and can be unticked. We record your actual final choice, the displayed copy, whether it started ticked and whether you changed it. Masjid-update delivery and newsletters are not enabled by this release. Phone verification, Apple or Google sign-in, notification permission and usage sharing never imply a separate email or announcement subscription. Any future communication service requires its own applicable choice and suppression checks.

Unlinked guests without a verified phone are removed after 90 days; other unlinked guests and usable service credentials expire after 180 days. Using the service again does not renew those limits. Linked account contact records and consent provenance follow account retention. Route response content is removed after 24 hours by daily cleanup, while its one-use marker lasts until guest deletion.

Deletion is acknowledged only after a separate recovery proof is durable. Failures remain retryable, and a completed guest deletion has a credential-bound retry marker for at most 24 hours. Deleting guest service data does not delete a signed-in account; account deletion covers its linked setup data. We retain keyed contact hashes for withdrawal, STOP or erasure suppression, without a raw phone number, email, account ID or guest ID in that suppression record. Suppression takes precedence over an older grant. Independent recovery proofs contain opaque identifiers and times, not contact boxes, verification codes or route responses.

Feedback includes your message, optional reply email, platform, screen, city name, operating-system version and app version/build when available. In the iPhone and Android apps it can also include widget refresh diagnostics: which refresh steps ran and how long ago, never locations or masjid names. When you are signed in, you can include your account details: your name, sign-in email and SMS-verified phone number, whichever your account holds. The feedback form lists them before you send and you can switch them off for that message. They stay encrypted in your account; we decrypt them only on our servers to show support who sent the message, and when support opens them, it is recorded. If you provide an email, we use it to send a confirmation with a copy of your message and support replies. When available, your verified sign-in address is filled in automatically; you can change or remove it before sending. A screenshot is optional and may reveal your location or personal details. After you take a screenshot on iPhone, we may prepare an image of our own app in memory and offer it for review. Nothing is sent until you choose Send feedback. You can remove the image or select your original screenshot instead. Image metadata is stripped before upload.

Your message and chosen screenshot are available to you and our support team through a private ticket conversation. A copy of your message, screenshot and any account details you included is also emailed to our support inbox, where it is kept with our support records and is not removed by the 30-day screenshot cleanup. A secure device cookie lets this device retrieve its own tickets; we never use your entered email alone to grant access. Clearing app/browser data or switching phones may remove access to those tickets. Screenshots stop being available after 30 days and are removed by scheduled cleanup. Restricted disaster-recovery backups can retain a deleted image for up to another 30 days. Support tickets, messages and optional reply emails expire 730 days after their last ticket activity, approximately 24 months. Original inbound email-review copies expire 730 days after receipt or their latest review, including pending and dismissed messages. You can request earlier deletion. We do not use feedback for advertising.

If you submit a timing report, we store its masjid, message, submission time, and any email you choose to provide. We use that email only to reply about your report. If you suggest a mosque website, we store its URL and your email so we can send you one email when the location is listed. Your email is not shown publicly or used for marketing. Prayer times may be connected after the location is listed.

Each report or suggestion sends our team an email alert with the masjid or website, your message, and the time. Your email address is never included in these alerts; only our team can see it, in a private signed-in inbox.

We use a daily hash of your IP address to limit abuse; the app does not store your raw IP in its database. Report content and suggestion contact details expire after 730 days, approximately 24 months, once no active support ticket needs them. Public prayer-source and listing records can remain. Contact us to request access or deletion.

Cloudflare hosts the website and stores accounts, cloud prayer history, reports and prayer-source data. Cloudflare Email Sending delivers requested support and listing emails. Twilio Verify is the conditional phone verification processor if that service is enabled later; it is not sending verification texts in this release. Apple and Google verify sign-in under their own privacy policies. Map providers may include Google, Apple and OpenStreetMap; Apple Maps and Google provide travel estimates. AlAdhan (aladhan.com) calculates prayer start times from a rounded location. Native maps and notifications use each phone's platform services.

We do not use advertising trackers. You can use Salah Route without sharing your location, and you can turn off native reminders or background location at any time.

Salah Route is a general-audience service. Optional sharing is off by default, with a neutral under-16 parental reminder. A parent or guardian can contact our Privacy Officer about a child's data. Location, sign-in and support are separate choices. We do not sell personal information or share it for behavioral advertising; Global Privacy Control never turns on sharing.

Cloudflare processes hosting, database, diagnostic and requested email data; Twilio would process phone verification only if separately enabled; Apple, Google, OpenStreetMap and AlAdhan provide the platform and map/time services described here. Their systems may process information outside your province or country, including the United States. PostHog would process optional product usage in the US if separately activated; its transport is currently off. Provider agreements, transfer safeguards and child consent requirements are subject to owner and counsel review before analytics activation.

To diagnose missing iPhone Lock Screen cards, the app records a small event trail when a card is requested, changes state, is completed, or is checked when you return. This does not continuously monitor the phone or prove that a card was visible. The local trail holds up to 64 events for seven days. For devices enrolled in the background-card service, reports include a random event ID, device registration, prayer-window identifier, card type, timestamps, app build and a fixed diagnostic reason. They contain no coordinates, mosque names, push tokens or free-form content. Guest reports remain on the device. Uploaded events are accessible only to the owner, capped at 200 per device, and removed after 14 days or when device registration is revoked or its account deleted. Restricted backups may retain them for up to 30 further days. Card diagnostics are separate from optional usage analytics.

Worker error logs follow the configured Cloudflare log retention. Aggregate diagnostic counters expire after 400 days. No longer log retention is promised without provider verification.

The iPhone app sends privacy-safe crash and hang reports to our server. They carry the app and iOS version and device model, with no account ID, location or message text.

The Android app has no crash reporter of our own. Its screens, like the website, can send a short error report when a page script fails. We remove email addresses, tokens, query strings and exact coordinates first. Google's map component on Android may send its own diagnostic data to Google under Google's policies.

The optional Friday checklist and its completion marks stay in private storage on this device. They are separate from your prayer log, cloud backup and usage analytics. Friday reminders can appear on your Lock Screen. Your phone controls background delivery, so updates may be delayed.

Signing in or out, switching accounts or deleting your prayer history clears account-specific checklist marks. Guest reminders remain available without signing in. You can export or clear your device-only checklist through its controls; it is not restored by cloud prayer-history backup.

The separate automatic-ending service starts off and is initially limited to an approved signed-in owner. If you explicitly enable it and the server confirms preparation, your phone sends a temporary Apple token for an already-running Tahajjud card, random job/activity/installation IDs, app build, delivery environment and a UTC end deadline. The job is linked to your current sign-in session and account generation to prevent old jobs surviving sign-out, expiry or deletion. It sends only an end message through Apple APNs; it cannot start or update cards. It sends no location, mosque, source, night ID, completion marks or analytics consent. Enabling it never enables usage sharing.

The server schedules an end for the Fajr or location-expiry deadline, whichever comes first, with immediate dismissal when Apple delivers it. Offline phones or delayed Apple delivery can delay removal; provider acceptance does not prove that a card disappeared. Active tokens are removed after success, permanent refusal or revocation. Temporary jobs and credentials expire no later than ten minutes after the original deadline, with a daily deletion backstop. Restricted disaster-recovery backups can retain those records for up to 30 days; recovery deletes all temporary jobs and sign-in sessions before service resumes. Turning this service off, dismissing the card or changing accounts queues exact-job revocation if offline; sign-out and account/history deletion also invalidate server jobs. An already-dispatched message cannot be recalled. Local immediate ending remains a fallback.

Enabling Tahajjud does not enable usage sharing. On iPhone, the general Share usage statistics choice also controls optional daily Tahajjud counts while the feature is enabled. Android does not send these optional Tahajjud counts. If you explicitly allow sharing, we count opt-ins, eligible last-third windows, successful activity starts and explicit completions by day. These are best-effort event counts, not people, attendance or obligatory prayer totals. This separate aggregate counter sends no night identifiers, prayer history, account or device identifiers, mosque details or coordinates. Independent random request keys prevent duplicate delivery for up to 24 hours; daily counters expire after 400 days. Counts below three are hidden from the admin dashboard. The network IP is used only by a temporary in-memory abuse limiter and is not stored with these counters.

Optional Tahajjud completion marks stay on this device, separate from the five-prayer log and its cloud backup. They are not recovered by signing in on another phone or included in your cloud history export. You can undo a mark or clear these completions in Settings. Deleting all prayer history or deleting your account also clears local optional marks and local event deduplication data; signing in or out, switching accounts, or a changed cloud history generation clears them too. Signing in or out, changing accounts or deleting all prayer history also turns off Tahajjud usage sharing. Turning off usage sharing prevents new events and cancels pending requests. Previously aggregated anonymous counts cannot be traced to you for deletion. Tahajjud events never enter crash diagnostics.

Whether and where you pray is religious information, which many privacy laws treat as sensitive. We collect it only when you log a prayer or the app logs one for you at a masjid (the "Log masjid prayers automatically" setting, which you can turn off in Settings), to show you your own log and keep its backup, or, with the explicit optional usage-sharing choice, in the anonymous Tahajjud aggregate form described above. Optional product statistics may also reveal religious interests and use a persistent installation ID as described above.

Salah Lock uses iPhone Screen Time. On Android, optional Salah Focus app pausing uses separately approved Accessibility access to identify which app is in front; it does not read screen text, screenshots or gestures. App choices and these observations stay on your phone and are not uploaded. Optional Do Not Disturb requires its own system permission. Leave-by alarms and the In Salah state stay on your phone too.

We never use prayer data for advertising, never share it with data brokers, and never combine it with other companies' data.

Privacy Officer, DhikrShare. Request access, correction, withdrawal or deletion, or raise a privacy complaint by emailing support@salahroute.com. We will update this page when the app's data practices change.