Risalah

Privacy Policy

Last updated 27 October 2026 · English only

What Risalah collects, what it does not, and what you can ask for.

This document is published in English only. A machine translation of a liability or data-protection clause can change what you are agreeing to, so translations will be published once they have been reviewed by a person.

1. The short version

Risalah collects the minimum it needs to run an account-based library and a set of prayer tools. We do not sell your data. We do not build an advertising profile of you. Our content analytics are aggregate-only by design: no user IDs, no IP addresses and no per-event rows are stored, so what we learn about which items are read is a set of counters rather than a record of who read them.

We do keep a security log of requests to our API, and it does include your IP address and, where you were signed in, your account. It is there to detect abuse and account takeover, it is not used to build a picture of your reading, and after ninety days the parts that identify you are stripped out of it — section 7 says exactly what goes. We would rather say that plainly than claim we hold nothing.

2. What we collect

What we collect when you use Risalah

Account details you give us: email address, username and display name; and optionally a phone number, gender, address, country, region, time zone, preferred language and preferred madhab. Only email, username and password are required.

Your password is never stored. We keep only an Argon2id hash of it, which cannot be reversed into your password.

Activity tied to your account: content you create, comments, likes, follows, bookmarks, collections, reading progress, reading history and your notification preferences.

A record of the choices you make about consent. When you accept the privacy policy and the terms, or answer one of the consent choices in the app while signed in, we record which version of each policy you accepted and whether you said yes to updates by email or by push notification and to analytics. Every change you make is kept as a dated entry, with whether you made it in the app, on the web or in Risalah Studio, so that we can show what you agreed to and when. We do not record the network address or the device a consent came from. If you are not signed in, your answer stays on your device and we keep nothing.

Your searches, if you use premium sync. They are saved to your account so that they follow you between devices, and you can clear them at any time from the app — clearing them deletes them, rather than hiding them.

Device location, only if you grant permission. Prayer times and the qibla are calculated on your device, and nothing is sent to us to do it. To show the name of the place you are in, the app asks your phone's own location service to name it. That service looks the position up with the company behind your phone's system — on most Android phones Google, and on an iPhone Apple — under that company's terms, and the lookup does not pass through us. The one time your coordinates are sent to us is to find mosques near you, and they are not stored: the request is answered, and the coordinates in it are not written down.

Location while the app is closed, on Android, only if you turn it on. With travel mode on, you can let the app keep your prayer times and adhan alerts right for where you are while it is closed. The app explains this before it asks, and it works only if you then choose "Allow all the time". It checks roughly where you are, to the level of a city, every fifteen minutes; when you have moved, it recalculates the times on your phone and names the new place as described above. Nothing is sent to us. The phone keeps only the place it is using now, your home place, and the last move it made, so that the app can tell you what changed; it does not keep a trail of where you have been. Section 8 says how to turn it off.

The state or province your device reports, if you have granted location permission and ask to see events near you. It is sent with that request so we can show events in your region rather than anywhere in your country, and it is not stored against you.

Push notification tokens, if you enable notifications.

Security and request records

Session and security records: the IP address, browser and device of each active session, so you can review and revoke them, and so we can detect account takeover. Failed login attempts are recorded to block brute-force attacks.

Request logs: for each request to our API we record the method and the path, the response status, how long it took, your IP address, your user agent and the device type, operating system and browser we read out of it, whether that user agent looked automated, and your account if you were signed in. We do not record the query string — the part of a web address after the question mark — so whatever a request carries there does not reach the log. These exist for security, abuse prevention and debugging.

Stored with each of those records: the approximate location our CDN derives from your IP address — country and region, and the city where it supplies one — whether the connection arrived over a VPN, a proxy or the Tor network, and a trust rating we calculate from those. We use them to detect abuse and account takeover, and to apply regional availability rules, which can withhold an item where it may not lawfully be shown. They do not by themselves suspend, restrict or ban an account: that decision is made by a named administrator and is recorded.

While a request is being answered our CDN also supplies approximate coordinates for your region and the network your address belongs to. Those are held in a temporary cache for fifteen minutes and are not written down.

What we record when an administrator acts

Administrative access records: when an administrator or moderator takes a significant action on the platform — including opening material of yours that is not public — we record who did it, what it concerned and when. These records are how we are able to tell you who has looked at something of yours.

What we record when you publish something

If you contribute a text, we ask you — before it goes for review — to say how it was made: written by you, written with the help of a model, translated, and if a model was involved, which one. We record the exact words you agreed to, together with who you are and when you agreed.

We keep the wording itself rather than a reference to it. What you agreed to is the sentence that was in front of you at the time, and that sentence changes as we revise it, so storing "version two" would tell you nothing a year later.

This is what stands behind the disclosure shown on an item: the person it names has affirmed it, rather than had it applied to them. It does not apply to the classical library, which was taken from published sources and has no author here to ask.

Identity documents, only if you apply to sponsor or to contribute

Reading Risalah never requires this, and we never ask a reader for it. It is asked for only when you apply to become a sponsor, or apply for a role that carries editorial authority over what others read — because a platform of religious knowledge has to be able to say who paid for a placement and who is answerable for a text.

If you make such an application we ask for: your legal name, date of birth, nationality, the type, number, issuing country and expiry of a government-issued identity document, an image of that document, a photograph of you, a phone number and a postal address. A sponsoring organisation is also asked for its registered name and number, its address, its authorised representative, and images of its registration document and that representative's identity document.

These files are held in private storage and are never served from our CDN or reachable by a link. They can be opened only by an administrator signed in with two-factor authentication, and every single time one is opened we write an audit record naming the person who opened it. If you ever want to know who has looked at your documents, write to us and we will tell you.

They are deleted thirty days after a decision is made — see section 7.

3. What we deliberately do not collect

Content, announcement and sponsored-placement analytics are stored as daily aggregate counters only — views, impressions, clicks and dismissals, and the total time an announcement was on screen, broken down by country and device category. Announcements and sponsored placements are also broken down by region and city; for content we count instead the kind of site a visit came from and any campaign tag it carried. No user IDs, no IP addresses, no device identifiers and no individual event rows are kept.

Some of these figures depend on your answer to analytics, which you give in Settings under Privacy and which is no until you say yes. If you have said yes, the announcements and sponsored placements you see, tap or dismiss, and the features you use, are added to their daily totals. If you have not, none of that leaves your device. A view of an item is counted either way, as the anonymous count described above. Saying yes adds to totals; it does not start a record about you. If you are signed in, the answer saved with your account is used on every device you sign in on; if not, the one saved on your device.

To count a view or an impression once rather than repeatedly, we use a salted, truncated visitor hash held in temporary cache for one hour and then discarded. It is scoped per item per day, so it cannot be used to link your activity across items or across days, and it is never written to the database.

We do not use third-party advertising or cross-site tracking SDKs.

We do not ask readers for identity documents. The verification described in section 2 applies only to people who apply to sponsor or to contribute, and no third party — including our infrastructure providers' staff — is given access to those files.

4. Why we use it

To provide the service: authenticate you, show your library, sync reading progress across devices, and send the notifications you asked for.

To keep the service secure: detect and block brute-force attempts and abuse, alert you to sensitive changes such as a password change or a login from a new device, and investigate incidents.

To improve the platform: understand in aggregate which content is read, and where the product is failing, using the aggregate counters described above.

To meet legal obligations where they apply.

Not to train machine-learning models on what you write as a reader without asking you. Your comments, the questions you ask, your notes and highlights and your searches are not used to train, fine-tune or ground any model unless you have separately agreed to it, and we do not sell them or license them to anyone. If we ever want to use any of them this way, we will ask first, as a choice of its own that is off until you turn it on, and say so here before we do. A work you submit for publication and sign a licence for is different: the Terms of Service say what that licence lets Risalah do with it.

5. Email

We send transactional email — verification, password reset, security alerts, and notice that an editor has credited a work to you — and, if you have opted in, notification and digest email. If you have not confirmed your email address, we remind you once a week, and stop after the sixth reminder.

Updates and newsletters go only to people who have said yes to updates by email. That choice has no effect on account, security and service mail, and the digests of your own activity follow your notification settings rather than it.

Every notification and digest message carries a one-click unsubscribe link and header. Unsubscribing takes effect immediately, requires no login, and turns off notification email without deleting any of your data. Security and account-critical messages are still sent.

6. Who else processes your data

We use a small number of infrastructure providers, acting on our instructions: a CDN and network provider that terminates connections and supplies the location and network signals described in section 2; object storage providers that hold media files; a search service; and an email delivery provider. Media is served through our own API rather than directly from storage, so storage URLs are never exposed to your browser.

If you configure an AI feature with your own provider key, what you submit for translation, summarisation, writing help, transcription or reading text from an image is sent to that provider under your account with them. Your key is encrypted at rest with AES-256-GCM and is used only for requests you initiate. What you sent and the answer that came back are kept in your job history in Risalah Studio, so that you can see them again, and they are deleted with your account.

Separately from anything you do, an administrator checking the library against a printed edition may send a photograph of a page from that edition to an AI provider to be read into text. What is sent is a page of a printed book rather than anything belonging to a reader, and it is sent as image data rather than as a link, because those scans are held in private storage with no public address. The request runs against an API key held by that administrator, who must be signed in with two-factor authentication, and every run is recorded.

We do not sell personal data, and we do not share it with advertisers.

7. How long we keep it

Account data is kept while your account exists, and for thirty days after you delete it — section 8 says what happens then. Session records end when a session expires or you revoke it.

Request logs are stripped of what identifies you after ninety days. The record itself stays; what we clear out of it is your IP address, your user agent and the device details we read from it, the link to your account, the region and city, and the VPN and trust signals. What is left is the path that was asked for, the method, what we answered, how long it took, whether the caller looked automated, the country, and the time.

That keeps the shape of our traffic — which paths are busy, an abuse campaign running across months — and ends the part of it that is a record of what you, personally, were reading. We keep the country because two letters with no address and no account attached to them describe traffic rather than a person. We would rather hold a log that cannot be turned against a reader than hold one that can and promise not to.

Where we are investigating abuse we may place an address or an account under a hold, which suspends that stripping for the records concerned. A hold names the person who opened it and the reason they gave. It expires, never more than a year from the day it was opened, and continuing past that means opening a new one with a fresh reason on the record. Opening a hold and releasing it are both written into the administrative log described next, which we keep indefinitely, so the record that a privacy promise was suspended outlives the suspension itself.

Administrative access records — who opened what, and when — are kept indefinitely where they record an administrator opening something sensitive, a change to what an account may do or who it belongs to, a suspension, a ban, a deletion or a restoration, a moderation, sponsorship or campaign decision, an API key issued or revoked, or a security event. They outlive the material they describe on purpose: section 2 tells you that you may ask who has looked at your identity documents, the documents themselves go at thirty days, and an answer that expired with them would be empty exactly when somebody needed it. Routine administrative records are deleted after two years.

Records of requests made under section 8 are deleted three years after the request is closed. A request that is still open is kept until it is closed.

Aggregate analytics counters contain no personal data and are retained indefinitely.

Identity documents are deleted thirty days after a decision on your application, whether we approved it or refused it. That means the image of your identity document, the photograph of you, and the document's number — all deleted, automatically, by a job that runs every day. Thirty days rather than immediately, so that a refusal can be appealed by someone who can still see what was refused.

What we keep afterwards is only what shows the check happened: your legal name, the type of document and its expiry date, which administrator decided, and when. Not the document, and not its number. The same rule applies to a sponsoring organisation's registration document and its representative's identity document; an organisation's registration number is kept, because that is a public register entry rather than a personal identifier.

If an application is still awaiting a decision, nothing is deleted — the clock starts at the decision, not at the application.

8. Your choices and rights

You can view and edit your profile, change your password, enable two-factor authentication, review and revoke sessions, change your notification preferences, and delete your account — all from Settings in the app.

Deleting your account closes it at once and destroys it thirty days later. In between, the account is closed rather than hidden: you cannot sign in, and it can be brought back only if you ask.

If you change your mind within those thirty days, write to support@risalahapi.net from the address the account used. Once we have confirmed it is you, we restore the account as it was — unless that address has since been used to open another account, in which case we cannot give it back. We restore an account only at its holder's request: never on anyone else's, and never on our own initiative. After the thirty days it has been destroyed and cannot be recovered.

When they are up we delete your profile and what is attached to it: your reading progress and reading history, your bookmarks, notes, highlights and collections, your comments, likes, follows and reviews, the questions you put to scholars, your saved searches, your sessions and notification tokens, your billing history, your AI job history if you used Risalah Studio's AI tools, and your identity records if you ever applied to sponsor or to contribute. A question that a scholar answered leaves its answer behind: that is published as the scholar's work, and may repeat what you asked.

A comment that other people have replied to is not removed outright, because that would take their replies with it. Its words are erased and it no longer names you; it stays only as a marker saying that a comment was removed, so the replies under it still make sense. The same applies when you delete a single comment yourself: its words stop being shown to anyone at once, and are erased thirty days later.

Reports you made about content or other people also stay, so that what a moderator decided keeps its record, but what you wrote in them is erased and they no longer name you.

Two other kinds of thing outlive the account, and you should know which before you decide. Records of what you did as a contributor or a reviewer — that a text was checked, and to what level — remain, with your name taken out of them. And work you published remains, because readers and other contributors depend on it: it stops being attributed to you, and is instead shown as the work of an account named "Removed account", which anyone reading it can see. The one exception is the licence credit on work you licensed under the Risalah Content Licence: you still own that work, so the credit the licence requires continues to name you. If you would rather your published work went too, ask us: we take it out of the library at once, and it is destroyed thirty days later.

Depending on where you live you may have additional rights over your data, including access, correction, deletion, portability and objection. Write to support@risalahapi.net and we will honour them.

When you write to us to exercise one of these rights, we keep a record of the request — the address it came from, what you asked, when, and what we did — so that we can show it was honoured. It outlives the account it concerned, and is deleted three years after the request is closed.

Location permission can be withdrawn at any time in your device settings. Prayer times will then fall back to a city you choose manually.

Travel mode's use of your location while the app is closed stops as soon as you switch travel mode off, choose a city yourself, or change the app's location permission to anything other than "Allow all the time".

9. Children

Risalah accounts are for adults: you must be 18 or older to create one. Anyone can read Risalah without an account. If we learn that an account belongs to someone under 18, we close it and delete it as section 8 describes. If you believe a child has an account, contact support@risalahapi.net.

10. Security

Passwords are hashed with Argon2id. Access tokens are short-lived and refresh tokens rotate on every use, with reuse treated as theft and the session revoked. Sensitive stored values — AI keys, backup codes, reset tokens — are encrypted or hashed. Traffic is served over HTTPS.

Identity documents are held in private storage separated from all public media, are never addressable by URL, and are readable only by an administrator holding two-factor authentication. Each access is recorded.

No system is perfectly secure. If you find a vulnerability, please report it to security@risalahapi.net rather than disclosing it publicly, and we will work with you on a fix.

11. Changes to this policy

We will update this page when our practices change and revise the date at the top. Material changes will be announced in the app or by email before they take effect.

12. Contact

Privacy questions and data requests: support@risalahapi.net Security reports: security@risalahapi.net