Privacy is the product.

Privacy policy

Effective: 12 August 2026 · Version: 1.4 (revised 30 August 2026) · Applies to: mudrus.com, the Mudrus desktop application, and the Mudrus iOS and Android applications.

Contact: [email protected]

A note on who this is written for

Mudrus is used by mosques to record children's Qur'an memorisation. Most of the people in this system are minors, and the adults responsible for them are trusting a mosque, which is trusting us. That shapes every decision below, and where a choice was available we took the one that collects less.

Two commitments are worth stating before the detail, because they are the ones that matter most and they are enforced in code rather than in policy:

1. Recitation audio is never sent to any third-party AI service. Automated analysis of a child's voice by an external model is not a feature of this product. Where speech recognition is planned, it is designed to run on the teacher's own device. See docs/ON_DEVICE_QURANIC_ASR.md. 2. A mosque's data is inaccessible to every other mosque, enforced by the database itself and not only by application code. See docs/SECURITY.md.

1. Who is responsible for the data

Under GDPR terms:

- The mosque is the data controller. It decides which children are enrolled, what is recorded about them, and who at the mosque may see it. - Mudrus is the data processor. We store and process that data on the mosque's instruction, and we do not use it for our own purposes beyond operating and improving the service as described in section 4.

If you are a parent or guardian and want data corrected or removed, contact your mosque first — they control it and can act immediately. If they do not respond, contact [email protected] and we will act within 30 days.

2. What is collected

2.1 About mosque staff (administrators, teachers, assistants)

2.2 About students (usually children)

We do not collect from students: home address, date of birth, school, medical or health information, biometric identifiers, precise location, government identifiers, or any special-category data under GDPR Article 9. There are no fields for these, so a mosque cannot enter them into a structured field.

Free-text notes are the exception, and are the one place a mosque could record more than intended. Notes are visible only to staff at that mosque with access to that student, are never included in the guardian or public verification views, and are covered by the deletion process in section 6.

2.3 About guardians

Name and contact details as provided by the mosque; portal visit timestamps; any messages exchanged with teachers; and consent records (section 3).

2.4 Automatically collected

The analytics system cannot record personal data by construction, not by policy. Every event and every property must be declared in a registry (src/lib/analytics/events.ts); anything undeclared is dropped before storage, no event may carry a student identifier, no event declares a free-text property, and numeric values are stored as bands ("10–24 students") rather than exact counts. This is enforced by tests that fail the build.

No third-party advertising, tracking or profiling SDK is present in any Mudrus application. There is no advertising identifier, no cross-site tracking, no data broker, and nothing is sold or shared for advertising.

3. Consent

Consent is recorded against the student, with a version and a cryptographic hash of the exact text shown at the time — a consent to a policy nobody can reproduce is not a consent. Seven kinds are tracked separately, and each can be granted or withdrawn independently:

research and marketing are listed because they are recorded and enforceable, not because either flow exists: Mudrus runs no research pipeline over student data and sends no marketing to guardians. Both are gated at the query layer the moment either does.

Consent types we deliberately do not offer yet. There is no WhatsApp or SMS consent toggle, because there is no WhatsApp or SMS message path for one to govern. A switch that promises to control something it does not control is worse than its absence, and these will be added when the messaging they refer to is.

Consent may be granted by a guardian in the portal, or recorded by a staff member when collected on paper — in which case the record names the staff member who entered it. Withdrawal takes effect immediately and is timestamped.

Withdrawal does something, in code, at once. Withdrawing ai_analysis deletes the analysis fields on every recitation in the same transaction that records the withdrawal. Withdrawing audio_storage makes the upload endpoints refuse new recordings for that student; recordings already stored are not destroyed by a consent change, because destroying a child's recorded work is a decision the family makes separately — the portal says so and offers the deletion request beside it.

COPPA. Mudrus is not directed at children and children do not create accounts. A student's record is created by their mosque under the mosque's relationship with the family, and verifiable parental consent is obtained by the mosque. Where a student portal login is issued, it is issued by the mosque to a specific child at the guardian's request and carries no messaging or public posting capability.

4. How the data is used

- To operate the service — showing teachers their students, recording progress, generating reports. - To secure the service — authentication, rate limiting, the audit log. - To bill the mosque — via Stripe; see section 5. - To improve the product — using the aggregate, de-identified analytics of section 2.4 only. This includes A/B testing, described below.

A/B testing

Some interface changes are shown to some mosques and not others, and the results compared, so that changes are made on evidence. What this involves:

- Assignment is computed from a hash of your user identifier and the experiment name. It is stable, contains no personal data, and requires no additional collection. - The measured outcomes are the registry-controlled events of section 2.4 — "an onboarding was completed", never who completed it or what they entered. - No student data is ever an experiment metric. No child's progress, attendance, or recitation is used to evaluate a product change. - Results are visible only to Mudrus platform administrators, as aggregate counts per variant.

Predictive analytics ("students who may need attention")

Mudrus flags students whose engagement has dropped, so a teacher can follow up. Honesty about what this is:

- It is a transparent weighted checklist, not machine learning and not a prediction about a child. Five signals — attendance rate, days since last recitation, accuracy trend, gap since last session, recency of enrolment — are weighted and summed. - Every contributing factor is shown alongside the score. There is no opaque model output, and a teacher can always see exactly why a student was flagged. - It runs entirely within one mosque. Nothing is compared across mosques and no data leaves the tenant. - It produces no automated decision with legal or similarly significant effect under GDPR Article 22. It sorts a list for a teacher; a human decides everything that follows. - A mosque may adjust the weights or disable the feature in its settings.

What we never do

We do not sell personal data. We do not share it for advertising. We do not use student data to train AI models. We do not use recitation audio for any purpose other than showing it to authorised staff at that mosque.

5. Third parties

Only these, and only for what is listed:

Railway — hosts the Socket.io real-time chat relay. Processes message content in transit (between connected clients, not stored), authentication tokens, conversation metadata (read-only database queries for access verification), and connection metadata. Message content does not persist on Railway's servers.

The relay runs in a single region — US East (Virginia, USA) — for every mosque, rather than following the mosque's selected storage region. What that means for a mosque outside that region is in section 9.

Payment card details never reach Mudrus servers. They are entered directly into Stripe's hosted fields. We store only a customer reference, a subscription status, and the last four digits.

No AI or speech-recognition provider ever receives a recording. This is the line the product does not cross, and nothing in the application transmits audio to any such service. Speech recognition is not built.

What an AI provider can receive, and only then, is text. Where a deployment has been given a provider key — OPENAI_API_KEY, ANTHROPIC_API_KEY or GOOGLE_AI_API_KEY — and where the guardian's ai_analysis consent is recorded as granted, the application sends: which passage is being recited, the child's age, how many surahs they have memorised, how long the recording ran, and up to 500 characters of the teacher's own note. No name, no identifier, no contact detail, and no audio. What comes back is a suggestion of what a teacher might listen for in that passage at that level — a prediction about the passage, not a measurement of the child — and the teacher's own grade remains the only real one.

Both switches must be on. With no key, the request is refused before it is built; with no consent, it is refused before that. The three providers are listed above and on the live register even where a deployment has configured none, for the same reason Resend and Sentry are: a processor in use and undisclosed is the failure this section exists to prevent.

Resend and Sentry are conditional. Each is engaged only where a deployment has set the environment variable that turns it on — EMAIL_PROVIDER_API_KEY and SENTRY_DSN respectively. They are listed here even where a deployment has not configured them, because a processor in use and undisclosed is the failure this section exists to prevent, and it has happened once already (see Railway, version 1.1).

Resend delivers the notification emails a mosque sends a guardian about their child. Such an email is a signal, not the news itself: it carries the child's first name, the mosque's name, the guardian's address and a link to the portal, and nothing more — not whether the child was absent, not a grade, not which surah, not a teacher's note, not an amount. What the message is about waits behind the portal's sign-in, which is the whole reason a signal is sent instead of the content. The one exception is the weekly summary, and it is the family's to switch on: only where the separate digest_content consent has been granted — off unless a guardian turns it on — does that email carry a child's progress rather than a link to it. Resend also delivers the website's contact form, which is an adult writing to Mudrus about Mudrus.

Sentry receives no student data. Error diagnostics are assembled field by field and scrubbed before they are sent, and the browser SDK is deliberately not installed — its automatic breadcrumbs would send student ids and guardian portal tokens to a third party.

The live register is at [/subprocessors](https://mudrus.com/subprocessors). It is generated from the same list the application code holds, records when each processor was added or retired, and states whether each one is actually engaged on the deployment serving the page. Where this document and that page disagree, the page is the current fact and this document is out of date.

Each is a data processor under a data processing agreement. We do not add processors without updating this document and notifying mosques.

6. Retention and deletion

A message and the record that it was sent are kept for different lengths of time, on purpose. What was actually said — the text of a notification, a message in a thread, a voice note — follows the first row above and is gone after 90 days unless your mosque has a compliance duty that requires longer. The fact that the mosque told you something, on which day, by which channel, and whether it arrived, follows the second row and is kept much longer. That split is what lets a mosque answer "were we told?" years later without holding what was said for years. The longer record is hash-chained and append-only, and it carries facts about the message and never the message itself.

Two audit logs, two retentions. The general audit log answers "who changed this?" and keeps 24 months. Privacy actions — an export, an erasure, a consent change, a missed deadline — are recorded separately, in a hash-chained log kept seven years, because they are the evidence that a legal obligation was met. Entries in it carry context and never content: what class of data was exported and how many rows were anonymised, never the child's notes or a message.

Deletion within the product is a soft delete first: the record becomes invisible everywhere in the application, including guardian and public views, and is excluded from every query by the database itself. It is then purged permanently on the schedule above. This exists so that an accidental deletion by a teacher on a Friday is recoverable on a Monday.

Erasure asked for by a family is a different door, with a different window. When a guardian requests deletion and the mosque confirms it, the record disappears immediately — from the mosque, from the family's own portal link, from everywhere — and then nothing irreversible happens for seven days. On day seven the recordings, photographs and free text are permanently destroyed, the record is anonymised where rows must be kept for integrity, and a deletion certificate is issued to the family listing what was destroyed, what was kept, and under which legal basis.

The seven days exist for one reason: a mistaken or fraudulent request against a child's record has to be survivable. Inside the window a request can be cancelled and the record returned. After it, it cannot, and the certificate says so.

What erasure reaches that families usually are not told about: the verbatim transcripts of recordings, the teacher's private notes, the free text in a recitation's analysis, the original spreadsheet row if the student was imported from one, uploads that were interrupted mid-transfer, and the change history the offline sync engine keeps. Copies held on a teacher's phone are deleted when that device next connects; a device that has not connected for 90 days or more is named on the certificate as an unreachable replica, because that is the only honest sentence available about it.

Erasure reaches the guardian as well as the child. A parent is two rows in this system — the entry in the mosque's contact book, and, if they ever had one, a sign-in account. Both are anonymised when the child's record is erased: the name, phone number, email address, password and any two-factor secret are removed and the account is closed. Their messaging preferences are deleted. The record of which channels they agreed we could contact them on is kept, because it is the proof that every message we ever sent was one they had allowed — but the network address it was recorded from is removed from it, and from the consent record we keep about the child, since an address is not part of that proof. None of this happens while another of their children is still enrolled. Those rows are that child's family's records too, and that family asked for nothing.

Certificates are the one deliberate exception. An issued certificate is a historical claim, and revoking it records a revocation rather than removing the row — a verifier must be able to tell a withdrawn certificate from a forged one, and both would look identical if the record were deleted. If the underlying student record is deleted, the public verification page reports the certificate as unknown and displays no name.

To request erasure: contact your mosque, or [email protected]. We respond within 30 days. Where erasure conflicts with a legal retention requirement (invoices), we will say so and erase everything else.

7. Your rights

Under GDPR, UK GDPR, CCPA/CPRA and comparable laws you may:

• Access the personal data held about you or your child
• Correct anything inaccurate
• Erase it, subject to section 6
• Export it in a portable, machine-readable format
• Restrict or object to processing
• Withdraw consent at any time, without affecting prior processing
• Complain to your supervisory authority

California residents: we do not sell or share personal information as those terms are defined by the CPRA, and there is therefore no opt-out to offer. You will not be discriminated against for exercising any right.

How to exercise them. Every guardian portal link has a Your child's data page behind it. From there, without an account and without asking anyone, you can see every consent and change it, ask for a copy of the record, ask for a copy formatted for transfer to another service, ask for the record to be deleted, and read the full history of what has been done with it.

Changing anything there asks for the last four digits of the phone number the mosque has for you. A portal link can be forwarded, and a page that can delete a child's record should not act on possession of a URL alone.

The mosque confirms each export and each deletion before it happens: they hold the relationship that can tell whether the person asking is really the family. We answer within 30 days, and the clock starts when you first ask — not when the mosque gets to it. If it is not answered in time, that is recorded as a compliance breach against the mosque and escalated to Mudrus.

You can also write to [email protected]. If your mosque has not responded, we will open the request on their system ourselves, dated from your first letter. We do not charge, and we do not require an account to make a request. We will verify your identity proportionately before disclosing data.

8. Security

Summarised here; the full architecture is in docs/SECURITY.md.

- Tenant isolation in three independent layers — Postgres row-level security on every tenant table, a query-rewriting database client, and API middleware. Each is sufficient alone; all three must fail together for one mosque to see another's data. Verified by an automated isolation test suite. - Passwords hashed with Argon2id. Never stored or logged in any recoverable form. Changing a password invalidates every existing session on every device. - Encryption in transit (TLS) and at rest. - Role-based access, with teaching assistants scoped to assigned students. - An audit log of privileged and destructive actions. - Rate limiting on authentication and other sensitive endpoints.

Known limitations are documented rather than hidden, in section 7 of docs/SECURITY.md. Multi-factor authentication is not yet available.

9. International transfers

Each mosque selects a storage region at signup. Data is stored in that region. Transfers outside it require the cross_border_transfer consent (section 3) and are covered by Standard Contractual Clauses where applicable.

Stripe processes payments globally and is certified under applicable transfer frameworks.

The real-time chat relay (section 5) is a single deployment in US East (Virginia, USA), not a per-mosque region. For a mosque whose selected storage region is outside the United States, live chat messages transit the United States while in flight. They are stored only in the mosque's own region — the relay does not persist them — but the transit itself is a transfer.

Two consequences we state plainly rather than leave for a reader to work out. Whether this transit requires the cross_border_transfer consent of section 3 under this policy's own rule above is [PENDING — LEGAL REVIEW]. And a mosque that needs to avoid US transit entirely can, today, simply not use in-product chat; every other feature stores and processes in the mosque's own region.

10. Children's privacy

Restated in one place, because it is the part that matters most:

- Children do not create accounts. Records are created by mosques. - Verifiable parental consent is obtained by the mosque before enrolment. - No advertising, tracking, profiling, or behavioural targeting is applied to any user, and specifically not to children. - Student data is never used to train AI models. - Recitation audio is never sent to a third-party AI service. - A student portal login, where issued, allows a child to see their own progress and nothing else — no messaging, no posting, no other child's record. - A guardian may request deletion of their child's data at any time.

11. Changes

Material changes will be notified to mosque administrators by email and in the product at least 30 days before taking effect. The version number and date at the top of this document change with every revision, and consent records store the version in force when consent was given, so it is always possible to establish exactly what someone agreed to.

Revision history.

12. Contact

• Privacy enquiries and rights requests: [email protected]
• Security reports: [email protected] (see docs/SECURITY.md §9)
• Everything else: [email protected]

Appendix — app store disclosure summary

For Apple App Privacy and Google Play Data Safety. Every answer below is verifiable against this document.