Privacy is the product.

Privacy policy

Effective: 12 August 2026 · Version: 1.0 · 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. Five kinds are tracked separately, and each can be granted or withdrawn independently:

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.

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:

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 receives any data. The application can be configured with AI provider credentials, but the feature is disabled and no recitation audio is transmitted to any such service.

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

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.

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: through your mosque, who can act immediately, or [email protected]. 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.

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.

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.