Privacy Policy

Version 2026-08-25. In force from 25 August 2026.

Older versions are kept. We will send you any of them if you ask at support@ya-habibi.co.uk. There is no archive inside the app yet, and saying there was one would be the kind of promise this document is trying not to make.

This document explains, in plain words, exactly what information Ya Habibi holds about you, where it is held, why we hold it, what legal basis we rely on, how long we keep it, who else ever sees any of it, and what happens to all of it when you delete your account. It was written by reading the app's own source code, its database migrations and its server functions on 25 August 2026, so it describes what the software actually does rather than what a policy of this kind usually says. Where a business decision has not been taken yet, this document says so in plain words rather than stating a position nobody has adopted. Where the thing missing is a registration or an appointment rather than a decision about wording, the table in section 1 says in words that it has not been made, because a blank tells a reader nothing and the position itself is something they are entitled to know. A policy that stated a retention period the software does not honour would be worse than a policy with a gap in it.

This document was prepared for review. It is not legal advice and it has not been reviewed by a qualified solicitor. Section 27 lists what a qualified person must sign off before Ya Habibi launches, and some of those items are not stylistic: they change what the software has to do.

Three companion documents carry the detail that would otherwise bury this one, and they are part of the same picture:

• Data retention (data-retention.md) is the full retention schedule: every category, its period, the basis for it, what triggers deletion, and what a legal hold changes.
• Law enforcement and disclosure (law-enforcement-and-disclosure.md) is what we require before we hand anything to the police or a court, and what we tell you.
• Cookies and device storage (cookies.md) covers the two websites, and What is stored on your phone (on-device-storage.md) covers the app.

1. Who we are and how to reach us

In short: Ya Habibi is the data controller. These are the details you need to write to us, and the ones that are still blank.

Ya Habibi is a Muslim app for iPhone and Android, with a web version at app.ya-habibi.co.uk and a marketing site at ya-habibi.co.uk. It brings together prayer times, the Quran, qibla, a worship tracker, a study library, a community called the Ummah, halal food listings, and a verification process for Islamic scholars and officials.

Data controller

Contact for anything in this policy. Data protection enquiries go to support@ya-habibi.co.uk.

The only other address that appears anywhere in the product is a contact address the app sends inside the User-Agent header when it asks OpenStreetMap's Nominatim service to look up a place name. That is a technical requirement of that service's usage policy and not a contact point for you.

2. The short version

In short: no advertising, no third party analytics, no trackers, no data broker. Ya Habibi does measure itself, in its own database. A short list of things that surprise people, said up front.

• No third party analytics, crash reporting, advertising or attribution software is in the app. Not Google Analytics, not Firebase, not Facebook, not AppsFlyer, not Sentry, nothing. This was verified by searching the whole of the app source, the iOS and Android projects, the web app and the server functions, and by reading pubspec.yaml, which declares no such package. No data broker receives anything and nobody is watching you use the app on somebody else's behalf.
• Ya Habibi does measure itself, and the previous version of this document denied it. Since migration 0175 and the client code beside it there is a first party analytics, crash reporting and install attribution system that writes to Ya Habibi's own database and to nowhere else. It exists precisely so that no analytics SDK is needed: an SDK would send a device identifier, an IP address and a screen name to a third country processor, and in a Muslim app "device X opened the Qibla at 04:12" is a statement about somebody's religion. What is actually being sent today is crash reports. The event and attribution paths are built and are not yet called from any screen. Section 4.11 is the full description, including the two things about it that are not yet right.
• We do not sell your data, and we do not share it for advertising. There is no advertising in the app.
• Prayer times, qibla and the Quran are computed on your phone. The app can tell you the name of the place you are standing in without asking any server, because an 18MB list of 235,206 places ships inside the app.
• Your position leaves the phone in only three situations, all listed in section 6, and all of them start with something you tapped.
• Your worship record never leaves your phone. The prayer tracker has no server copy, and it deliberately survives signing out.
• Your prayer calculation settings, including sect and madhab, are now copied to our server. They used to live only on the phone and this document used to say so. Since migration 0163 they are mirrored so that the web version shows you the same times as the app. Section 5.2 says exactly what that means, because a sect setting is the most direct statement of religious belief in the product.
• Nobody at Ya Habibi sees your face or your identity document during the check itself. The capture and the comparison happen inside the verification provider's software. One qualification, stated in section 7.3: on a check that passes, the provider sends us back the portrait it captured, and we hold it for twelve months.
• Private messages are not end to end encrypted. We can read them, and we do read them when a conversation is reported, under the rules in section 11.
• When you press Translate, the text is sent to Google. That includes private messages. Section 9 says exactly what goes and what does not, and marks the decision that is still open.
• You have to have an account to use any of it, including the parts that need no network. That is a deliberate product decision, explained in section 3.
• The Ummah is for adults. The rule is 18, signup asks for your date of birth before it asks anything else, and the rule is enforced by the server rather than by a screen. Section 21 is honest about the one gap left in that.

3. What an account requires, and why everything sits behind one

In short: an email address, a username and a password, then a display name, whether you are a brother or a sister, your country, and your date of birth.

To create an account we ask for an email address, a username and a password. Onboarding then asks for a display name, whether you are a brother or a sister, and your country.

Your date of birth belongs to the same step. It is held in app_private.identity_links, which is outside the schema any app can reach, has deny-all row level security, and is returned by no function to any client, including yours. The app is told one thing: whether the account is an adult. It is never told the date. Section 21 explains what the answer changes and states the two gaps in it honestly.

Every part of the app sits behind that sign-in, including prayer times, the Quran and qibla, which technically need neither an account nor a network. That is a deliberate decision by the owner, taken so that the app is one connected place rather than a set of tools with a community bolted on. Whether that can be justified is one of the questions section 27 puts to a qualified person, because requiring an account for a feature that needs no data at all is hard to justify as necessary for the performance of a contract.

Signing in uses your username and password only. Your username is never exchanged for your email address on your phone, deliberately, because a service that turns a username into an email address is an email harvester. The check is made inside the database. See section 22.

4. Everything we hold, why, on what basis, and for how long

In short: the complete list, using the real names of the tables, so that it can be checked.

Tables whose name begins public. hold things the app can read through a controlled function. Tables whose name begins app_private. are never readable by an app at all. auth.users belongs to Supabase's authentication service.

Abbreviations for lawful basis are Article 6(1) UK GDPR: (a) consent, (b) performance of a contract with you, (c) legal obligation, (ea) a recognised legitimate interest under the Data (Use and Access) Act 2025, (f) legitimate interests. Where special category data is involved the Article 9 condition is given as well, and section 5 explains the whole scheme. "How long" is summarised here; the full schedule with the reasoning is in data-retention.md, and where a period is not yet enforced by the software the entry says so.

4.1 Account and identity

4.2 The Ummah

4.3 Photographs, video and voice notes

Five things about media that you should know.

1. 1.Images are stripped of EXIF data before they are uploaded. That removes the GPS coordinates, camera and timestamp that phones write into photographs.
2. 2.Video is not stripped and cannot be. The app has no video remuxer, so a video keeps whatever metadata your phone wrote into it, which on many phones includes where it was recorded. The composer warns you before you attach a video.
3. 3.Voice notes exist and this document did not mention them until now. The message composer can record audio, using your phone's microphone, and send it as an attachment in a conversation. The recording is made only while you hold the control, it is stored like any other message attachment, and it is subject to everything section 8 says about private messages. Your phone will show you its own recording indicator while it is running.
4. 4.The public buckets are genuinely public, and which ones they are matters. Post and comment media, avatars and restaurant photographs sit in buckets marked public in the storage service, so somebody who has the direct link to one of those files can open it without an account. Do not post a picture you would not be willing for a stranger to hold a copy of. Message attachments and voice notes are not among them. A previous version of this document said that attachments to messages sat in the public bucket. That was wrong, and wrong in the direction of alarming you: since migration 0124 they have had their own private bucket, reachable only by the two people on the conversation. Scholar documents and halal certificates are private too.
5. 5.Deleting a post removes the record, and the bytes are a separate operation. Postgres cannot delete from the storage service, so removing the underlying file is a second step that something outside the database has to perform. Migration 0177 built the first half of that: when a post goes, or an account is erased, the bucket and path of every file involved is written to app_private.storage_erasures in the same transaction as the row, so the database cannot forget the path before the file is gone, and an interrupted run resumes rather than silently completing. The second half does not exist. Nothing yet reads that queue and deletes the files. Until something does, a file whose direct URL somebody kept may still resolve after the post is gone. This is stated as the limitation it is, and it is the sharpest thing in RISK-NOTE.md.

4.4 Private messages and talking to staff

A ticket opened through the public contact form on the marketing site carries a name and an email address that nobody has proved belongs to them. The row says so, in a column called email_verified, and staff are not to treat an unverified ticket as authenticated by the person it claims to be from. That matters most for a request about somebody's account: see section 18 on how we verify who you are.

Private messages are not end to end encrypted. Ya Habibi can read them. In normal running nobody does, and since migration 0106 the ordinary server key has had its read permission on public.messages and public.conversations revoked outright, so there is no route to a private message except through a report. Section 11 explains what a staff member has to do before that route opens.

4.5 Translation

4.6 Safety, reports, moderation and the investigations regime

Where a report or a moderation record concerns an allegation of a criminal offence, it is also personal data relating to criminal offences under Article 10 UK GDPR, and we rely on Schedule 1 Part 3 paragraph 36 DPA 2018 (extension of the Part 2 conditions) and, for child sexual abuse material specifically, paragraph 35. Reliance on those conditions requires an Appropriate Policy Document, and that document is appropriate-policy-document.md in this folder.

4.7 Verification, scholars and biometrics

Section 7 explains this in full. The rows are here so that the table is complete.

4.8 Halal Food

Two facts about reviews that matter. The star rating is anonymous to readers and the words are not. Since migration 0116 the rating is never returned beside anybody's name, including your own, because a score with a face on it drifts upward and stops being an average of what people think. Your own rating comes back only to you. A business cannot hide or delete a review of itself. Only Ya Habibi staff can hide a review, and the row records that they did and why. That is deliberate: the Digital Markets, Competition and Consumers Act 2024 makes concealing genuine negative reviews a banned practice, and a business with a hide button is a business that will use it.

Most of a listing is information about a business rather than about a person. Where the business is a sole trader, its address, phone number and exact coordinates are that person's personal data, and everything in this policy applies to them.

4.9 Prayer, the Quran, the Qibla, the study library and the tracker

Most of this never leaves your phone, and the exceptions are listed in section 6 and in on-device-storage.md. Since migration 0163 there is one server copy that this document previously denied: app_private.prayer_prefs, in 4.1. Your Quran reading position, your reciter, the study library and your worship tracker have no server copy at all.

4.10 The marriage area

The database contains tables for a marriage feature (public.marriage_profiles, marriage_photos, app_private.marriage_reports and others). That feature is not reachable in the app, so no marriage data is being collected from anybody.

4.11 How the product measures itself

In short: Ya Habibi has its own analytics and crash reporting, they write to Ya Habibi's own database and to no third party, and the previous version of this document said they did not exist.

This section is new and it corrects a statement rather than adding a detail. Until this version, section 2 and section 14 both said there was no analytics and no crash reporting anywhere in the product. Migration 0175 and the client code beside it made that untrue, and it stayed in the document. It is set out fully here.

Why it is first party. An analytics SDK does not receive "an event". It receives a device identifier, an IP address, a screen name and a timestamp, and in this app "device X opened the Qibla at 04:12" is a statement about somebody's religion sent to a processor in another country. That would need an Article 9 condition, a transfer mechanism, a data protection test and a consent most people would not give if the question were put honestly. The same rows landing in Ya Habibi's own Postgres, behind the row level security everything else already sits behind, need none of it. That is the reason there is no SDK, and it is a data protection by design decision in the sense of Article 25.

What is deliberately not stored, and it is checked twice. No IP address. No advertising identifier. No precise location. No free text from anything you wrote: an event carries a name from a vocabulary and a handful of scalars, the client drops anything that is not a number, a boolean or a string of 64 characters or fewer, and the database enforces a size limit on top of that, so that a post body cannot arrive in an analytics table by accident. A stack trace is code rather than something you typed.

The device identifier is not your account. It is generated on your device, kept in your phone's or browser's own storage, and survives signing out. It is stored beside your profile id rather than instead of it, so that the part of the funnel before anybody has an account can be measured without every row becoming personal data the moment somebody signs in. On the web build it lives in your browser's local storage.

What is actually happening today, as opposed to what is built. Crash reports are being sent: two error handlers are installed before the first screen is drawn, and a crash or a caught error produces a row. The event and attribution paths are complete on both sides and nothing in the app calls them yet, so no screen views, taps or install sources are being recorded as at the date of this version. This is said because "we have analytics" and "our analytics is receiving data" are different statements and you are entitled to the accurate one.

Three things about it that are not right yet, stated rather than left to be found.

1. 1.The retention periods above are not being applied. The function that deletes on those schedules, app_private.analytics_prune(), exists and is correct. Nothing runs it: it is on no schedule, unlike the hourly maintenance job that enforces every other period in this policy. A period nothing enforces is a sentence, and this document does not get to count it as a control until something calls it.
2. 2.There is no way for you to switch it off. The client has a working opt-out that stops the device queueing anything rather than sending a flag and trusting the server to ignore it, and no screen in the app offers it. Objecting under Article 21, and the free and simple objection route the statistical purposes provisions require, are both answered by putting that switch on a settings screen. Until it is there, write to support@ya-habibi.co.uk and we will stop it for your device by hand.
3. 3.Erasing your account does not remove your analytics or crash rows, and does not even unlink them. The rows carry your profile id, and they are written to release it if the profile row is ever deleted. An erasure does not delete that row, it tombstones it, so the link survives along with the rows. Nothing in the erase touches these three tables. That is on the list in section 20.

5. Religion, and other special category data

In short: holding an account here reveals that you are a Muslim, that is special category data, and we rely on your explicit consent for it.

5.1 The plain fact

Article 9(1) UK GDPR prohibits processing personal data revealing religious belief unless a condition in Article 9(2) applies, on top of an ordinary Article 6 basis. Ya Habibi is a Muslim app. Holding an account is itself capable of revealing your religion. So are, among other things:

• the sect setting (Sunni or Shia) and the madhab you choose for prayer calculation, which since August 2026 are held on our server as well as your phone;
• which circles you join, particularly ones tied to a school of thought;
• what you post, comment, save and like;
• the credentials a scholar submits;
• a review saying you eat only at certified halal restaurants.

We are not going to pretend otherwise, and a policy that buried this would be worse than useless.

5.2 What is on the phone, and what is not

Your worship tracker, your Quran reading position and reciter, and your study library progress have no server copy at all. The tracker in particular exists only on your handset, which is why signing out deliberately leaves it alone.

The prayer calculation settings are different, and this changed. Until migration 0163 the sect, the madhab and the rest of the calculation lived only in the app's own settings store, and the previous version of this policy said in terms that they were never sent to our servers and that there was no server column for them. That is no longer true. The whole settings object is now mirrored to app_private.prayer_prefs as one opaque blob, so that the web version of Ya Habibi shows you the same times as the app rather than a different school's defaults. The server does not interpret the blob. It still contains your sect and your madhab, which means we hold, on a server, an explicit statement of your religious affiliation.

Three consequences, stated rather than buried:

1. 1.It is processed on the basis of explicit consent under Article 9(2)(a), see 5.3.
2. 2.It must be deleted when you delete your account. The code to do that was written in migration 0177 and it does not currently run to completion, for the reason section 20 gives, so for most accounts it is still not deleted.
3. 3.Religious belief must be declared on the Google Play Data Safety form and as Sensitive Info on the App Store privacy label. Earlier internal guidance in this repository said not to declare it, on the strength of the sentence that is no longer true.

5.3 The conditions we rely on, layered

5.4 Gender

The app records whether you are a brother or a sister, because it uses that to run gender scoped circles and to let you switch off messages from the opposite gender, which the server then enforces in both directions. Gender is not special category data under Article 9, but it is sensitive, and the app treats it that way: it can only be changed once every 90 days and the change is recorded.

5.5 Date of birth

A date of birth is not special category data on its own. Combined with a country it goes a long way towards identifying one person, and combined with a religion, which every row in this database already discloses, it is a sensitive combination attached to a unique key. That is why it is held in app_private.identity_links, is returned to no client, and is never published. See section 21.

5.6 Biometric data

Biometric data used for identification is special category data. Section 7 explains what happens to it in full.

6. Location

In short: your position is worked out and used on your phone. It leaves it in three situations, all of which start with something you tapped.

6.1 Start with the strong part

Ya Habibi answers the question "where am I" without asking anybody. An 18MB gazetteer of 235,206 places ships inside the app and is copied into its own storage on first run. When the app needs to turn a position into a place name, it looks it up in that file on your phone. No lookup request goes anywhere. This is unusual, it costs 18MB of your storage, and it is a data protection by design measure in the sense of Article 25 UK GDPR: the least intrusive means of doing the job was chosen and built.

GPS is read in exactly one place in the whole app, in the prayer state code, and only if you have granted location permission. If you have chosen a place by hand, the place you chose always wins over the satellite position, every time. Nothing in the app quietly re-derives your location behind that choice.

Prayer times, the qibla direction and the calendar are then computed on your phone from that position. None of them needs a network connection.

6.2 The three times a position leaves your phone

1. 1.Halal food search. When you search for halal food near you, your latitude and longitude are sent to our own server, to the restaurants_near function, so it can work out which listings are close. It goes to us and to nobody else, and it is not stored.
2. 2.Masjid search. When you search for a masjid near you, an approximate latitude and longitude are sent to OpenStreetMap's Overpass service, at overpass-api.de and overpass.kumi.systems. Those are third party servers run by the OpenStreetMap community. They also learn your device's IP address, as any server does when your phone connects to it directly. Approximate means rounded to three decimal places before it is sent, about 110 metres. The narrowest search this ever runs covers 8 kilometres, so nothing is lost from the answer, and whoever runs that server cannot tell which street the request came from.
3. 3.A restaurant owner setting their location. If you run a business and set its exact position on the map, that position is stored on the listing and shown publicly, which is the point of it.

6.3 Three related cases that are not your position

• Place search (Nominatim). When you type a place name into the search box and tap search, the text you typed is sent to OpenStreetMap's Nominatim service. Your own position is not sent. The request happens on an explicit tap, never as you type.
• Elevation (Open-Meteo). The coordinates of the place you have selected are sent to Open-Meteo to get its elevation, which slightly changes sunrise and sunset. That is the selected place, which may or may not be where you are.
• Address lookup for a food listing (Google Places). When a business owner is setting up a listing, the address text they type is sent through our places-address server function to the Google Places API so that the address can be resolved into structured fields and coordinates. This is about the business's address, not about your position, and it is disclosed here because Google was not named anywhere in the previous version of this policy.

6.4 Permission

The app does not ask for location permission during onboarding. It asks when you do something that needs it. If you refuse, you can set your place by hand and everything except "near me" search keeps working.

7. Scholar verification and biometrics

In short: a third party checks your face against your document, we never see either, a human at Ya Habibi makes the decision, and one picture does come back to us.

7.1 What happens

If you apply to have a scholarly role published on your profile, one part of the process is proving that you are the person named on your documents. That check is carried out by Didit (https://didit.me), a third party identity provider. You take a live photograph of your face and a photograph of an identity document, and Didit compares them and checks for liveness.

7.2 What Didit gets, and what it does not

The camera capture and the comparison happen inside Didit's own software running on your phone. The images travel from the camera to Didit. They do not pass through Ya Habibi and nobody here sees your face or your document during the check.

When we start a session we send Didit two things only: the identifier of the workflow to run, and an opaque token. That token is an HMAC-SHA-256 value computed under a salt that is different for each area of the app, so Didit cannot use it to connect one part of Ya Habibi to another. We do not send Didit your email address, your phone number, your name, or your username.

7.3 What Ya Habibi keeps, and the one qualification to "nobody sees your face"

We keep:

• whether the check passed or failed, and when;
• which method was used;
• a reference for the session and for the provider's workflow, so a decision can be traced back;
• a refusal code, if it was refused;
• the portrait the provider captured during a passing check, so a tick can be granted later without asking you to show your face a second time.

That last line is the qualification to the headline in section 2, and it has to be read with it. A facial image held by us is biometric data when it is used to identify you, whatever route it took to get here.

We do not keep the document number, the date of birth on the document, the address, the document image, or any biometric template. We never had most of them, and we do not keep the document type or the issuing country either.

Retention: after 12 months the detail goes and the answer stays. A maintenance job clears the session reference, the workflow reference and the captured portrait from any check older than twelve months. What is left is the decision, the method and the date. That is deliberate: the decision has to survive, because it is what stops a refused check being run again and again until it passes.

Two defects in that, stated rather than glossed:

1. 1.The twelve month clock keys on the row's `updated_at` column, not on the date of the decision. Any update to the row restarts it.
2. 2.The clock still runs independently of your account, although the fix is written. Migration 0177 destroys the portrait as part of the account erase rather than waiting the twelve months out. That code does not currently run to completion, for the reason section 20 gives, so for most accounts the position is still the old one: delete your account in month one and the portrait is cleared in month twelve. Illinois and Texas both have biometric statutes with destruction deadlines that the old behaviour does not meet, and Illinois carries a private right of action, so this is not a housekeeping item.

7.4 Consent, and the published retention schedule

The lawful basis for the biometric part is explicit consent under Article 9(2)(a). Before the camera opens you are shown what is about to happen and you have to agree. Your agreement is recorded in app_private.biometric_consents with the version of the wording you agreed to. That table deliberately stores no IP address, no device fingerprint and no user agent: it is a record of consent, not a surveillance log.

Withdrawing consent writes a new row rather than deleting the old one. That is on purpose. Erasing the record of consent would destroy the proof that the processing already carried out was lawful when it happened. Withdrawal stops any further processing and you can ask us to delete the verification result at the same time.

This section is also Ya Habibi's published biometric retention and destruction schedule, which some jurisdictions require to be a public document rather than an internal one. In its own words: the biometric identifier collected is a facial image and the face comparison performed on it by Didit; the purpose is to confirm that the person applying for a religious credential is the person named on their identity document; the portrait we hold is destroyed twelve months after the check, and in no case later than three years after your last interaction with Ya Habibi; the document image and any template are never held by us at all.

7.5 A person decides, not software

A human being at Ya Habibi makes the decision. The provider's result is one input and never the decision itself. A reviewer looks at your documents, at the name you applied under, at the name on the profile and at the name read off the identity document, and forms a judgement, because names across transliterations, marriages and conversions are exactly the thing software gets confidently wrong. There is therefore no solely automated decision here. See section 16.

7.6 If you are refused

You are told, in a sentence a person wrote, and a stable refusal code is stored so the app can offer the right next step. You keep your account, your profile and everything else. Only the credential is refused. You can apply again, and you can ask us to review the decision by writing to support@ya-habibi.co.uk.

7.7 The documents themselves

The ijazahs, certificates and appointment letters you upload go to the private document store, which has no read policy of any kind. No app key can download from it, including yours. Staff read the file through a server route that logs every opening, and since migration 0165 only a member of staff holding the reviewer badge or higher may open it at all.

Retention, precisely: if the application is refused, withdrawn or revoked and no role is published on your profile, the document records are deleted 30 days after that decision, and the application itself, including the name on your documents, your phone number and what you wrote, is deleted after 12 months. Thirty days rather than immediately so that somebody appealing still has the evidence they sent. Until migration 0177 there was a hole in that: a scholar whose application was granted and who then deleted their account kept both their documents and the legal name read off their identity document, because the sweep only reached refused, withdrawn and revoked applications. The erase now removes them whatever the application decided, subject to section 20.

The same honest limitation as section 4.3 applies. Deleting the record removes the file from everything in Ya Habibi that could reach it. The bytes sit in a storage service a database job cannot delete from; the path is now written to the deletion queue described in section 4.3, and nothing yet drains that queue.

7.8 We telephone the institution, and one known gap

We telephone the body named on your documents, and that is a disclosure about you to a third party. A photograph of an ijazah proves that a document exists. It does not prove that the named institution issued it, that it was issued to you, or that it has not since been withdrawn, and one telephone call to the issuer is the only thing that answers any of the three. So a reviewer rings the seminary, the mosque or the awarding body, on a number they found for themselves, and asks.

What that call tells the institution is that a person of your name has applied to Ya Habibi claiming a religious credential from them. That is personal data about you, and because it is a religious credential it is special category data, so it is set out here rather than left implied:

• The basis is your explicit consent under Article 9(2)(a), on the same footing as the documents themselves. Applying for a published religious credential is asking us to check it, and this is the check.
• What is disclosed is the minimum that makes the question answerable: your name as it appears on the documents, and what you say the institution awarded you. Nothing about your account, your posts or anything else in this policy travels with it.
• The call is recorded in writing. Since migration 0176, app_private.scholar_institution_checks holds which body was rung, the number actually dialled, where that number came from, who answered, what they said in the reviewer's own words, the outcome, and the handle of the member of staff who made the call, copied onto the row at the moment it was written. It is append only: a call that turned out to be wrong is a second row, never an edit.
• A number the applicant supplied does not count. The approval gate counts only a confirmation reached on a number the reviewer found independently, because a confederate answering a mobile number printed on a letter can confirm anything at all. This protects you as much as it protects the product: it is what stops somebody using your certificates under their own name.
• The institution is named in section 14 as a recipient.

Referee details are collected in the app and stored nowhere. The application form asks for a referee's name, phone number and permission to contact them. There is no server storage for any of it. So it is not held anywhere and we are not going to claim it is held securely, because it is not held at all.

8. Private messages and voice notes

In short: one to one, request-gated, capped at five open conversations, not end to end encrypted, and readable by staff only under an investigation.

Messages are one to one only, between adults, and start as a request the other person has to accept. You can have at most five open conversations. You can switch off messages from the opposite gender, and the server enforces that in both directions, so switching it off also stops you starting one.

You can attach an image or a voice note recorded through your phone's microphone. A voice note is a message like any other and everything in this section applies to it.

Message bodies are cached on your phone so a conversation opens instantly. on-device-storage.md lists exactly what that cache holds.

Messages are not end to end encrypted. We can technically read them. In ordinary running nobody does, and the database now enforces that rather than trusting it: migration 0106 revoked the ordinary server key's ability to read public.messages and public.conversations at all, so the only route into a private conversation is a report, and since migration 0164 that route requires a signed, time limited investigation with a written reason. When staff do read a reported conversation they read the whole of it, both sides, because half a conversation is not evidence of anything. The app tells you this on the report row, before you tap it.

Staff Live Chat is a conversation with Ya Habibi staff that appears at the top of your Messages list. It is stored in the support tables, not the messages tables, and staff read all of it. That is the point of it.

9. Translation, and what goes to Google

In short: when somebody presses Translate, the text goes to Google. That includes private messages. This was not disclosed before and it is now.

Ya Habibi can translate what people write into 195 languages. Nothing is translated until somebody asks for it: there is no background translation of the feed.

When a translation is requested, our translate server function sends the text to Google Cloud Translation v2, at translation.googleapis.com. Five kinds of text can travel that way:

Interface strings are additionally sent to Google's Gemini API, at generativelanguage.googleapis.com, which is a large language model. Interface strings are the app's own words, not yours.

What this means, said plainly.

• Google is a recipient of your content. The previous version of this policy listed every recipient and ended with the sentence "There are no others." That sentence was wrong. Google is named in section 14 now.
• For a public post, the person who wrote it made it public, and Article 9(2)(e) carries the disclosure. For a private message it does not. The other person in that conversation did not press anything, did not make anything public, and is not told. There is no version of the current design in which that is comfortable.
• This is not settled, and there are only two honest answers. Either a recorded, version stamped consent is taken from both people in a conversation before a private message in it can be translated, or the operation is removed for messages and translation is left to posts, replies and bios, which their authors published. Section 27 lists it as one of the decisions a qualified person has to make.
• A processor contract and a transfer mechanism are required. Google Cloud's data processing addendum has to be accepted and recorded, the transfer to a United States recipient has to sit on Standard Contractual Clauses with the UK Addendum, and a transfer risk assessment has to be completed. See section 15.
• The engine used for interface strings has two keys configured, one of which is a Google Places key used as a fallback. Which Gemini tier that project is on has not been confirmed. On Google's free tier its terms permit the content sent to be used to improve its products and to be read by people. Only the app's own interface strings travel that path today, so the exposure is small, and small is not the same as confirmed.
• A machine translation is not a human one. It can be wrong, and it can be wrong about something that matters. When you are shown a translation the app says so, in a line under the words reading "Translated", or "Translated from" and the language it was written in, and the original is always one tap away. What that line does not say is that the translation was made by software rather than by a person, so take every translation you read in the app as machine made.

10. Reports, warnings, suspension and appeals

In short: you report, a person reads it, nothing is automatic, and any decision about you comes with the reason in the words of the person who wrote it.

10.1 What is recorded when you report something

You can report a post, a comment, a profile, a message or an entire conversation. The flow gives you nine reasons, narrows once, and asks you to confirm. What is stored is: what you reported, the reason you picked, anything you typed, your account id, who was reported, and whether the report is open, actioned or dismissed.

The person you reported is never told who reported them. There is no route in the software that gives them your name and no screen that shows it.

What is actually reported is worked out by the server, not by the app. The app says "this post", and the server resolves what that means from its own records. You cannot report a conversation you are not in.

Reporting a conversation hands staff the whole conversation, both sides, including your own messages. The app says so on the row before you tap it.

10.2 What happens next

Nothing is removed, hidden or suspended automatically because of a number of reports. A person reads every report. Brigading does not work here.

Staff can dismiss the report, warn you, suspend the account, or close it permanently. The database refuses to record anything except a reinstatement without a written reason, and that exact sentence is shown to the person it is about.

• A warning appears as a sheet you have to acknowledge before you can carry on.
• A suspension shows you a screen with the reason, and lets you write an appeal. One appeal is open at a time. If the appeal is granted, the account is reinstated in the same operation.
• A permanent closure reaches the phone immediately.

The Community Guidelines describe this from your side and set out what you are told.

10.3 The Digital Services Act

For people in the EU, this arrangement is how Ya Habibi meets the Digital Services Act's requirements on notice and action (Article 16), statements of reasons (Article 17) and internal complaint handling (Article 20). Two gaps are recorded honestly in the Community Guidelines and in RISK-NOTE.md: the outcome of a report is not currently sent back to the person who filed it, and the author of a removed post is not currently notified. Both are Article 16 and Article 17 obligations for a service in scope, and both need building.

11. Who inside Ya Habibi can read your data

In short: not everybody, not without a written reason, not without it expiring, and not without a log.

This section describes controls that most privacy policies do not have to describe, because most products do not have them. They were built in migrations 0164, 0165 and 0166 and they are the answer to "who at Ya Habibi can read my messages, and what stops them".

1. 1.Nothing is readable by default. Row level security is on and set to deny for every table in the database. No app reads a table. Every read goes through a controlled function that checks who you are and returns only what you are allowed to see.
2. 2.A staff badge is not one thing. There are three, in order: moderator works the queues where somebody is waiting on us (reports, appeals, support, live chat); reviewer may additionally open the evidence, which means scholar documents and identity images; admin may additionally change the shape of the place. A new badge starts at moderator, and raising it is a separate, audited act.
3. 3.Reading a person's account requires an investigation. An investigation is a row naming who opened it, over which subject, on what basis, and in their own words, with a minimum length so that "checking" is not a reason. The staff member's handle, display name and standing are copied onto the row at the moment of signing, because the point of a signature is what was true when it was given.
4. 4.There are two bases and only two. report means a report came in and the investigation is bound to it, and the subject must be the subject the reporter named. investigation means a member of staff went looking, which is allowed, has to be justified in prose, and is time boxed harder.
5. 5.It expires. Report-bound investigations last 30 days. Staff-initiated ones last 7 days. Expiry is enforced inside the function rather than by a job, so a lapsed investigation stops working the moment it lapses.
6. 6.Every read is logged, and a read that cannot be logged does not happen. app_private.access_log gets a row for each read of personal data, naming the investigation, the staff member, the function that did the reading and the subject. The log line is written in the same transaction as the read, with no exception handler around it.
7. 7.The last ungated route was closed. Migration 0166 revoked the remaining function that returned a person's whole account standing without an investigation.

Two consequences follow for you, and one of them is unusual.

• If you ask us what we hold about you, that answer includes the record of who read it and why. See section 18.
• Erasing your account does not erase that log. It exists to protect you, deleting it would destroy the only evidence that staff access to your data was itself controlled, and it is kept for six years under Article 17(3)(b) read with Article 5(2). This is the narrowest exception in this policy and it is stated rather than hidden.

12. Notifications

In short: prayer alerts are local to your phone. No server can reach your device.

Ya Habibi sends local prayer alerts only. There is no push provider in the app: no Firebase, no OneSignal, no direct Apple push integration, nothing. No server can send your phone a notification because no server knows how to reach it. Every alert is scheduled by the app on your own device.

Permission is requested only when you tap something that needs it, never during onboarding.

The app keeps a delivery ledger on your phone, of up to 300 entries with a 30 day retention, recording for each alert the prayer, the time it was due, the time it was armed, what happened, and whether you opened the app from it. This is there so that a missed alert can be diagnosed. It is never uploaded. The one field in it that is measurement rather than machinery is dealt with in on-device-storage.md.

In-app notifications, the bell, are a separate thing and are held on the server. They disappear from your view after 24 hours and are deleted at 90 days.

13. What is stored on your phone and in your browser

In short: two documents cover this in full, one for the app and one for the web.

• on-device-storage.md lists every key and file the phone app writes, what each one is for, whether it is strictly necessary, and whether it survives signing out.
• cookies.md covers ya-habibi.co.uk and app.ya-habibi.co.uk, which are websites and therefore genuinely raise the question people expect a cookie notice to answer.

The short version for the app: the place you are using, your prayer calculation settings, your Quran position and reciter, your notification settings and delivery ledger, your theme, your worship tracker, your profile as the device last knew it, your conversation list and message bodies, the first page of each feed, your circle memberships, and an 18MB place database. Signing out sweeps almost all of it and deliberately keeps seven things, including your worship tracker, because losing your prayer record because you signed out would be an act of vandalism.

The short version for the web: your session token, your prayer place, your Quran position, your tasbih state, your worship tracker and which tab you last had open in the study library. There are no advertising cookies, no analytics and no tag manager on either site.

14. Who else ever receives anything

In short: the complete list, with what each one gets. If it is not here, it does not receive anything.

There is no analytics provider, no crash reporting service, no advertising network and no attribution or install-tracking service anywhere in the app, the web app or the marketing site. This was verified by searching all four codebases and by reading the app's dependency manifest, which declares no such package. It does not mean there is no analytics or crash reporting: there is, it is Ya Habibi's own, it writes to Ya Habibi's own database, and section 4.11 describes it in full. The distinction is the whole point of building it that way, and it is a distinction this document previously failed to draw.

We do not sell personal data, and there is nobody to sell it to.

We disclose personal data to the police, a court or another authority only where a legally valid demand requires it, and we tell you where we are lawfully allowed to. law-enforcement-and-disclosure.md sets out exactly what we require, what we refuse, and what we publish.

If Ya Habibi is ever sold or merged, the data goes with it, and you will be told before it does.

15. Where the data is, and transfers out of the UK

In short: the mechanism for each recipient, and the ones that are still unpapered.

Transfers out of the United Kingdom are lawful only with a mechanism behind them: the UK's adequacy regulations for the EEA, the UK International Data Transfer Agreement, or the UK Addendum to the EU Standard Contractual Clauses, in each case with the data protection test the ICO's January 2026 guidance requires. Where a United States recipient is certified under the Data Privacy Framework, we do not rely on that alone: two predecessor frameworks have been struck down, a challenge to the current one is before the Court of Justice, and the Standard Contractual Clauses are signed as well so that an invalidation changes nothing.

An Article 28(3) processor contract must be in place with Supabase, Google, Didit and Brevo, and a transfer mechanism must be identified and papered for anything leaving the UK and EEA. None of that is verifiable from the source code, none of it is confirmed today, and all of it must exist before launch. If Ya Habibi is offered in Brazil, Turkey or Saudi Arabia, those countries require their own separate instruments, and in Turkey's case notification to the regulator within five working days of signature.

16. Automated decisions

In short: nothing here decides anything significant about you by machine.

Nothing in Ya Habibi makes a decision about you by automated means alone that produces a legal effect or a similarly significant effect.

• Verification is decided by a person. The provider's result is one input.
• Moderation is decided by a person. Nothing is removed or suspended by report count, and no automated system issues a warning, suspends an account or closes one.
• Rate limits and sign-in lockouts are automatic, but they are short, mechanical and reversible: you wait fifteen minutes.
• The age rule is automatic, and it is a rule rather than a judgement: it compares a date you gave us with today's date. If you believe the date on your account is wrong, write to support@ya-habibi.co.uk and a person will correct it.
• The feed is ordered by arithmetic on the age of a post, its likes and its replies, with a floor so that new voices are seen. It does not build a profile of you and it makes no decision about you. Article 14 of the Digital Services Act requires the terms of a service to describe any algorithmic decision making it uses in moderation and curation, and the Terms of Use describe this ordering in general terms.

The Data (Use and Access) Act 2025 replaced Article 22 UK GDPR with Articles 22A to 22D, and kept the stricter rule for decisions based on special category data. Because the decisions here are human, the point does not arise, but this policy cites the current provisions rather than the repealed one.

17. How long we keep things

In short: every category has a period, the periods are in one place, and the ones the software does not yet enforce are marked.

The full schedule is data-retention.md. It gives, for each category: the period, the legal basis for keeping it that long, what triggers the deletion, and whether the software enforces it today.

Two principles run through it.

We do not keep anything "just in case". Article 5(1)(e) requires personal data to be kept no longer than is necessary, and an undefined retention period is itself a breach of it. A retention schedule with a blank in it is the finding, not the mitigation.

A specific open matter suspends the ordinary period, and nothing else does. Where a report, an appeal, a complaint, a legal claim, or a request from a law enforcement authority or a court concerns particular material, that material is placed under a hold and is kept until the matter closes and any period for challenging its outcome expires. Every hold names the matter, the material and a review date. When the matter ends, the hold ends and the ordinary period applies. There is no holds table in the database today, so a hold is a note kept and applied by hand rather than a state the software enforces. That is weaker than it should be, and it is said here rather than left to be assumed.

18. Your rights, and how to use them

In short: all of them, free, answered within a month, and here is which ones we can do well today and which ones take us longer.

If you are in the UK or the EU you have the rights below. They are free to use. We answer without undue delay and in any event within one month of receiving a request we can act on, extendable by two further months for a genuinely complex or numerous request, in which case we tell you within the first month and tell you why. Where we reasonably need more information to identify you or to understand what you are asking for, the clock does not run while we are waiting for it.

How we check who you are. We require the request to come from the account, or from the email address registered to it. We will not ask you for a copy of an identity document to answer a subject access request about an account you can already sign into. A request that arrives through the public contact form, where nobody has proved they own the address, is not treated as authenticated and we will ask you to write from the account instead.

What we redact. A subject access request gives you your data, not somebody else's. Where a record contains information about another person, for example the identity of somebody who reported you, or the other half of a conversation, we remove what we cannot lawfully give you and tell you that we have done so. Where telling you about a disclosure would prejudice the prevention or detection of crime, an exemption in Schedule 2 DPA 2018 applies and law-enforcement-and-disclosure.md explains it.

19. Complaining to us about your data

In short: you can complain to us directly, we will acknowledge it within 30 days, and there are two ways to reach us.

Since 19 June 2026 UK law gives every person a right to complain to the controller about an infringement of their data protection rights, and requires the controller to facilitate that, to acknowledge it within 30 days, to investigate it without undue delay and to tell you the outcome. That duty applies to every organisation regardless of size, including this one.

Two routes, and you can use either.

1. 1.Electronically, through the support form inside the app or the contact form at ya-habibi.co.uk. Say in the first line that you are making a data protection complaint, so that it is routed correctly rather than treated as a support question. You will be given a reference such as YH-7F3K-2Q9 that you can quote.
2. 2.By email or post, to support@ya-habibi.co.uk or to the address in section 1.

What we will do. Acknowledge receipt within 30 calendar days. Investigate without undue delay. Take appropriate steps to respond. Tell you the outcome and what we did.

The in-app support system allows one open ticket at a time, so that the queue cannot be flooded. That limit is not allowed to stand in the way of a data protection complaint. If the form will not let you open a ticket because you already have one, send the complaint by email instead and it will be handled. No data protection complaint is turned away because a support ticket was already open.

Going to us first does not take away your right to go to the ICO, and you do not have to come to us first. See section 24.

20. What deleting your account actually does

In short: the account closes at once, the erase runs within 48 hours, a much wider erase was written in August 2026 and has a fault in it that stops it finishing for most accounts, and all of that is set out here rather than glossed over.

There is a "Delete my account" row in your profile menu.

Immediately when you confirm: the account is marked closed. Every part of the app that checks the flag stops working for it at once. You are signed out, and signing in tells you the account has been closed rather than that your password is wrong. There is no undo.

Then, at a randomly chosen moment within the next 48 hours: the erase runs. The moment is randomised independently for each area of the app, on purpose, so that watching rows disappear tells an observer nothing about which account they belonged to. The job that drains the queue runs hourly.

What the erase does today, exactly:

• your display name, your bio and your avatar are blanked;
• your profile is marked deleted, which takes it out of search, out of follower lists and out of profile pages;
• your username on the profile row is replaced with a tombstone that nobody can hold, so that a post you wrote cannot go on displaying a name that now belongs to somebody else;
• your username is released back into the pool with a 30 day cooldown before anybody can take it;
• every post and every reply you wrote is withdrawn. They leave the feed, your profile, search and every list they appeared in, at the same moment. They are marked as withdrawn rather than deleted outright, and that is deliberate: replies other people wrote underneath them belong to those people, whose rights are not engaged by your request, and deleting your post outright would take their words with it. Nothing in the app can reach a withdrawn post again;
• the link between your sign-in record and your profile is cut.

What survives on purpose:

1. 1.Replies other people wrote. They belong to the people who wrote them.
2. 2.The record that staff suspended or closed an account. Otherwise deleting an account would be a way of erasing a suspension, and the same person could come straight back.
3. 3.The moderation record: reports, warnings, appeals, staff actions, investigations and the access log, for the periods in data-retention.md, on the basis of Article 17(3)(b) and (e). Article 17(3) permits retention, not continued ordinary use, so a retained record is used only for the purpose that justified keeping it.
4. 4.The consent record in app_private.biometric_consents, because deleting the proof that completed processing was lawful destroys the only evidence in your favour as well as ours.
5. 5.A block somebody else set against you should survive, because deleting it would put them back in front of a person they chose not to see. That is the intended design and it is not what migration 0177 does: the erase as written removes every block naming the erased account, in both directions, so a person who blocked you loses that block when you leave. It is recorded in RISK-NOTE.md and it should be corrected to delete only the blocks you set.

The wider erase, and the fault in it. This is the most important paragraph in this section and it is not comfortable.

Migration 0177 was written in August 2026 to close almost every gap this section used to list. It extends the erase to your prayer settings including sect and madhab, the four translation caches, your follows, blocks, reactions, reposts and circle memberships, your notifications, your date of birth, the captured portrait from an identity check, a granted scholar's documents and legal name, and your email address in the sign-in record. It unlinks your private messages and your support threads rather than deleting them, for the reason given below. It writes the bucket and path of every file of yours to a deletion queue in the same transaction as the row that named it.

It does not run to completion. Two of the statements in it set a database column to nothing where the database does not permit nothing: the author of a halal food review, and the sender of a private message. Either one raises an error, and because the whole erase for one account is a single unit of work, the error undoes everything the erase had already done for that account and the account is put back in the queue to be tried again an hour later, where it fails in the same way. The failure is recorded as a warning and nothing else, so it is quiet.

What that means for you, in plain terms:

• If you have ever sent a private message, or written a review of a halal food listing, the erase currently does nothing at all for your account. Not the wider erase, and not the blanking and withdrawal listed above either, because the two run as one operation. Your account stays closed and unreachable, and nothing about it is removed.
• If you have never done either of those things, the erase runs and does everything in the list above.

That is a defect in a single migration and the fix is small. It is recorded in RISK-NOTE.md. It is stated here because a privacy policy that described the erase as it was intended to work, while it does not work, would be exactly the kind of false promise this document exists to avoid. Anyone who has asked to be erased and wants to know whether it completed can ask at support@ya-habibi.co.uk and will be told.

What no version of the erase reaches, fault or no fault:

• the underlying image, video and audio files. The path is queued for deletion, and nothing yet reads that queue, so the file is still there. For anything in a public bucket, a direct URL that somebody kept still resolves;
• your private message bodies. They are unlinked from you rather than deleted, deliberately: a conversation has two people in it, and the other person's record of what was said to them is theirs. Their author is removed; the words stay. A hard period for that tail is recommended in data-retention.md, six months from the erasure, and it has not been settled or built;
• your support threads and live chat, unlinked for the same reason: a support thread is the record of how a complaint was handled;
• your restaurant reviews. They are anonymised rather than deleted, so that deleting an account is not a route to erasing criticism of a business. Note that the code as written also blanks the words of the review, which goes further than data-retention.md says it should;
• your saves, your reactions to replies, and the conversation itself including who had read what;
• the record of which anonymous posts were yours;
• your analytics and crash rows, and the pseudonymous device identifier on them. See section 4.11;
• the record that your gender setting was changed.

Backups. A deleted record can persist in an encrypted backup until that backup rotates out. It is never restored into live systems, and if a restore ever happens the erasure is applied again immediately. The backup retention period for the project's hosting plan has not been confirmed, and this section will state the figure once it is.

What is on your phone is on your phone. Delete the app to remove the worship record and the rest of the local store. Deleting your account does not clear your handset.

21. Children

In short: the Ummah is for people aged 18 and over, the rule is enforced by the server rather than by a screen, signup now asks the question, and the one gap left in it is stated here rather than hidden.

Minimum age for the Ummah: 18. That is stricter than the law requires. The UK age of digital consent is 13 and most of the EU sits between 13 and 16. It is the owner's decision and it is the safer one, because the Ummah carries direct messages between people who do not know each other.

How the rule works. Signup asks for a date of birth. It is stored in a table no client can read, and no function returns it to any app, including yours: the app is told only whether the account is an adult. The rule is then enforced as a refusal inside the server functions themselves rather than as a screen the app draws, because a client-side age gate is a suggestion.

What an under-18 account cannot do: post, comment, react, repost, save, follow, join a circle, message anybody, or read the feed, a profile or a search result. That is the whole social realm.

What an under-18 account can still do: prayer times, qibla, the Quran, the study library, the prayer tracker, the tasbih, the names, halal food listings, its own profile and settings, support, reporting somebody, reading why their account was suspended, and deleting their own account. Those last three matter: an age rule that made it harder for a young person to report abuse or to leave would be worse than no rule.

The question is now asked, and one gap is left.

A previous version of this policy said that the signup screens did not yet ask for a date of birth, and that the gate therefore passed everybody. That is no longer true, and it was checked rather than assumed before this sentence was changed. The date of birth is the first step of onboarding, before anything else is asked, it cannot be skipped, and the app refuses to move past it until the server has confirmed in a second read that the date was actually stored, because an answer that never reached the server would be the client telling somebody a lie about their own account. The phone app, the Android app and the web version at app.ya-habibi.co.uk are built from one codebase, so it shipped in all three at once.

The gap that remains. Accounts that existed before the question was added were not asked, and an account with no date of birth is treated as an adult. That is deliberate, and it is what keeps every existing account working rather than locking people out of an app they already use. The set is bounded and small, the software can report its exact size at any time, and the honest remedy is to ask those accounts once, in the app, before launch.

Age assurance, and what a date of birth is not. Asking for a date of birth is not "highly effective age assurance" in the sense Ofcom uses, and it does not by itself answer the Online Safety Act's children's access assessment or take the service outside the ICO's Age Appropriate Design Code. It is a real improvement on asking nothing and it is not the end of the work. The three assessments the Online Safety Act requires, the illegal content risk assessment, the children's access assessment and the children's risk assessment, have not been done, and the record-keeping duty in section 23 of that Act has not been met. That is the largest single piece of unfinished regulatory work in the product, it needs specialist advice, and section 27 puts it second.

If you believe a child has an account, email support@ya-habibi.co.uk and we will look into it and close the account if that is the right outcome.

22. How the data is protected

In short: facts about how the software is built, not aspirations.

• Every table denies everything by default, and a new table cannot forget to. Row level security is on and set to deny for every table. A database event trigger attaches the deny-all policy to any table created after it, so the protection is a property of the schema rather than something somebody has to remember. Nothing is read by an app directly. Every read goes through a controlled function that checks who you are and returns only that.
• The ordinary server key cannot read private messages. That permission was revoked outright in migration 0106, so the only route to a conversation is a report.
• Reading a person's account requires a signed, time limited, logged investigation. See section 11.
• Staff badges are least privilege and start small. See section 11.
• Your username is never turned into your email address. A service that answers "what email address goes with this username" is an email harvester, so we do not have one. The comparison happens inside the database.
• An unknown username costs the same as a wrong password. The database checks a decoy password hash when the username does not exist, so timing cannot be used to work out which usernames are real.
• Sign-in is rate limited. Ten failed attempts against one username in fifteen minutes locks that name for fifteen minutes, and there is a global ceiling across the whole service.
• Writing is rate limited too, per action and per account.
• Photographs are stripped of EXIF metadata before upload.
• Video metadata cannot be stripped. The app has no video remuxer. The composer warns you. This is a limitation, stated as one.
• Scholar documents cannot be downloaded by anybody with an app key, including the person who uploaded them, and only a reviewer or above can open one at all.
• A message attachment is reachable only by the two people in the conversation. The bucket is private and the rule is the narrowest one that works: not "anybody signed in", which is every account in the app, and not "the sender", which would stop the person you sent it to seeing it.
• A telephone check on a scholar's institution counts only if the reviewer found the number themselves. A number that arrived with the application is recorded, because it happened, and it does not satisfy the approval gate. See section 7.8.
• Unmasking an anonymous author is logged, with the reason, every time.
• A sender identity for outgoing mail is a row in a table, not a text box, and two identities are reserved so that a letter cannot be sent in the founder's name by whoever was in a hurry. Every letter sent from a Ya Habibi address is logged, without its body.
• Everything travels over HTTPS.

No system is perfect. If you find a security problem, email support@ya-habibi.co.uk. There is no published vulnerability disclosure policy and no security.txt file yet.

If a personal data breach happens and it is likely to result in a risk to people's rights and freedoms, we report it to the ICO within 72 hours of becoming aware of it, as Article 33 requires, and we tell the people affected directly where Article 34 requires it. We keep a record of every breach, whether or not it was reportable.

23. Changes to this policy

In short: the date at the top changes when the software does, and you are told before a significant change takes effect.

We update this document whenever the software changes what it does with your data, and the date at the top changes with it.

When a change is significant, meaning it affects what is collected, what it is used for, who receives it, or how long it is kept, you are shown a notice in the app before the change takes effect, and the previous version remains available. There is no public archive of superseded versions yet: ask at support@ya-habibi.co.uk and we will send you any of them.

Where a change relies on your consent, we ask again. Consent to old wording is not consent to new wording, which is why the consent records carry a version string.

24. Complaints to a regulator

In short: you can go to the ICO at any point, and you do not have to come to us first.

If you are unhappy with how we have handled your data, tell us first at support@ya-habibi.co.uk, because most things are quicker to fix directly. Section 19 explains the formal route.

You also have the right to complain to the regulator at any point.

United Kingdom, the Information Commissioner's Office:

• Website: https://ico.org.uk/make-a-complaint
• Helpline: 0303 123 1113
• Post: Information Commissioner's Office, Wycliffe House, Water Lane, Wilmslow, Cheshire, SK9 5AF

European Union: under Article 77 EU GDPR you may complain to the supervisory authority in the member state where you live, where you work, or where you think the problem happened. A list is published by the European Data Protection Board at https://edpb.europa.eu.

Our representative in the European Union. Ya Habibi has not yet appointed a representative in the European Union under Article 27. Until it does, people in the EU should write to support@ya-habibi.co.uk.

You can also take a claim to court under Article 79.

25. California residents

In short: this section is offered whether or not the statute applies to us yet.

This section uses the language of the California Consumer Privacy Act as amended by the California Privacy Rights Act.

Whether Ya Habibi meets any CCPA business threshold has not been confirmed. On the face of it none is met: the app is free, it sells nothing, and it has very few accounts. The threshold to re-test as the app grows is the one about the personal information of 100,000 California consumers, which for a global Muslim app is reachable. Until a threshold is met this section is offered voluntarily rather than because the statute requires it, and the rights in it are honoured either way.

Categories of personal information collected, using the statute's own list: identifiers (email address, username, account identifiers, IP address, and the pseudonymous device identifier in section 4.11), internet or other electronic network activity (which posts were on your screen, and the app usage events and crash diagnostics in section 4.11), geolocation data (in the cases in section 6), audio, electronic and visual information (photographs, video and voice notes you upload), biometric information (processed by our verification provider, and a portrait retained by us for twelve months), professional information (the credentials a scholar submits), and sensitive personal information (religious beliefs, precise geolocation, the contents of messages, and biometric information used for identification).

We do not sell personal information and we do not share it for cross-context behavioural advertising, as those terms are defined in the CCPA. We have not done so in the twelve months before the date at the top of this document, and there is no advertising in the app. We do not knowingly sell or share the personal information of anybody under 16.

Sensitive personal information is used only for the purposes described in this document: running the service you asked for, verifying an identity you asked us to verify, translating text you asked to have translated, and keeping the community safe. We do not use it to infer characteristics about you. Because of that, the right to limit its use does not restrict anything we are doing, but you can still ask. Sending a post that reveals religious practice to Google for translation is a disclosure of sensitive personal information, and the position that it is neither a sale nor a share depends on Google being a service provider under the statute. Whether Google Cloud's CCPA service provider terms are incorporated into the contract has not been confirmed.

Your rights: to know what we collect and why, to a copy of it, to correct it, to delete it, to opt out of sale or sharing (there is nothing to opt out of), and to limit the use of sensitive personal information. We will not discriminate against you for using any of them.

How to use them: email support@ya-habibi.co.uk. We verify the request by matching it to your account. An authorised agent may act for you with written permission.

Other United States states. Every state privacy law now in force except California, Utah and Iowa requires opt-in consent before processing sensitive data, and every one of them lists religious beliefs as sensitive. The explicit account consent described in 5.3 is what answers that, and it is the same single build that answers Article 9(2)(a) in the UK and the EU. Global Privacy Control signals sent to our websites are honoured; since there is no sale, sharing or targeted advertising, there is nothing for them to switch off.

26. Other countries

In short: the app is on both stores worldwide, and several countries have rules we cannot meet by writing a paragraph.

Ya Habibi is available wherever the two app stores operate. Some countries impose obligations that are decisions rather than drafting: appointing a local representative, registering with a national authority, keeping data inside the country, or agreeing to give a government access to user data. For a product whose database discloses religious affiliation and, for many accounts, sect, the last of those is not a formality.

Which markets Ya Habibi is offered in at launch has not been settled, and local advice is needed for each one. The countries that need a decision rather than a sentence include Saudi Arabia (data localisation and registration with SDAIA), Turkey (VERBIS registration and a local representative), Indonesia (PSE registration, which commits the operator to government access to user data), Quebec (a declaration to the regulator sixty days before a biometric database operates, which cannot be done retroactively), Brazil (a publicly named data protection officer and Brazilian standard contractual clauses) and Malaysia (a notified data protection officer and 72 hour breach notification).

27. What still needs a solicitor

In short: this document was prepared for review. These are the decisions a qualified person has to make, in the order they should be dealt with.

This policy was written from what the software actually does. It has not been reviewed by a qualified solicitor and it is not legal advice.

1. 1.The Article 9 condition for simply having a Ya Habibi account, and the consent step that must follow. Holding an account in a Muslim app reveals religious belief. Article 9(2)(e) does not cover it, because signing up is not making something public. Explicit consent under Article 9(2)(a) is the answer this policy adopts, and the software does not take one yet. A solicitor must confirm the condition, weigh the Article 7(4) freely-given objection, and approve the wording. This is the single biggest legal question in the product.
2. 2.The age position, and the three Online Safety Act assessments. A date of birth is now collected, asked for at signup in every client, and stored server side, and section 21 states the one gap left in it. The illegal content risk assessment, the children's access assessment and the children's risk assessment have not been done, the record-keeping duty in section 23 of the Act has not been met, and the deadlines for all three passed in 2025. Ofcom is running an enforcement programme against exactly these duties.
3. 3.The duty to report child sexual exploitation and abuse content to the National Crime Agency. That duty is in force, it requires registration with the NCA before a report can be made, and it carries urgency-tiered timeframes. Nothing in this product registers. The Community Guidelines promise the reporting as an absolute, so this has to be operationally real before launch, together with arrangements for the welfare and supervision of the staff who handle the material.
4. 4.A data protection impact assessment. Article 35(3)(b) makes one mandatory for large scale processing of special category data, which is every account here. It also engages biometrics, behavioural tracking, invisible processing, children's data, and machine translation applied to religious content. It has not been done, it must be done before the processing rather than after, and several answers in this policy depend on it.
5. 5.The Appropriate Policy Document. Written and in this folder as appropriate-policy-document.md. A solicitor should confirm it meets Schedule 1 Part 4 paragraph 39 DPA 2018 and that the Schedule 1 conditions claimed are the right ones.
6. 6.Translation of private messages. Section 9. Both-party consent, or turn the operation off. This is a build decision that a lawyer should settle.
7. 7.ICO registration, the DPO question, and the two EU representatives. Section 1. The controller itself is no longer an open question: it is DAPPER TRADING LTD, company number 8800299, and section 1 names it, its registered office and its VAT number, which answers Article 13(1)(a) and the trading disclosure duty in sections 1202 to 1206 of the Companies Act 2006. The four things still missing from that table are appointments and registrations nobody has made: the ICO registration, which is a fee and a form and should be done first because it is the cheapest to fix; the Article 37 DPO question, which needs either an appointment or a written reasoned decision that the condition is not met; the Article 27 UK GDPR EU representative; and the Article 13 Digital Services Act EU legal representative. The Digital Services Act transparency database obligation in Article 24(3) applies even to a micro enterprise, and it requires that Article 13 representative to exist first.
8. 8.Processor contracts and international transfers. Section 15. Nothing is verifiable from source code and all of it must be papered.
9. 9.Retention periods, and the holds mechanism. data-retention.md proposes a period for every category and marks which are enforced. A solicitor should approve the periods, in particular the six-month tail on a deleted person's message bodies and the six-year default on moderation records, and the software must then enforce them.
10. 10.The erasure gaps in section 20. A solicitor should say how far Article 17 requires each of them to go, so that section 20 can be shortened rather than qualified. Before any of that, the fault described in section 20 has to be fixed, because until it is, an Article 17 request from anybody who has sent a private message completes no part of the erase at all, and that is an infringement rather than a design question. The storage bytes and the retained message tail are the two design questions that matter most once it is fixed.
11. 11.The first party analytics and crash reporting in section 4.11. Three questions, and none of them is answered by the fact that no third party receives the data. Whether legitimate interests is the right basis or whether the statistical purposes provisions of the Data (Use and Access) Act 2025 are the better route; whether writing and reading a persistent device identifier in the storage of a phone or a browser engages regulation 6 of PECR and Article 5(3) of the ePrivacy Directive, which turns on whether it is strictly necessary and it is not; and what the objection mechanism has to look like, given that the switch exists in the code and is on no screen. cookies.md reaches the same question from the website side and its answer must match this one.
12. 12.The legitimate interests assessments. View counting, rate limiting, security logging, link previews, and the retained suspension record. Adopting Article 6(1)(ea) for the safety and crime-detection processing removes the need for several of them.
13. 13.Biometrics outside the UK. Illinois requires a published retention schedule and a written release before capture, and carries a private right of action. Texas requires destruction within a year of the purpose expiring. Quebec requires a declaration to its regulator sixty days before a biometric database operates. Section 7.4 is written to serve as the published schedule; a solicitor should confirm it is enough, or advise geo-restricting the verification flow.
14. 14.Requiring an account for offline features. Prayer times, qibla and the Quran need no account and no network. Requiring one is hard to justify as necessary for a contract, and Apple guideline 5.1.1(v) says the same thing from a different direction.
15. 15.Whether the CCPA applies at all, and whether section 25 is an obligation or a voluntary commitment.
16. 16.The Digital Services Act position for EU users, including the micro-enterprise exemption in Article 19, the notice-and-action and statement-of-reasons duties that survive it, and what has to be published where.
17. 17.Which countries Ya Habibi is offered in. Section 26.

Version history

2026-08-25. The version in force.

2026-08-14. Superseded.

Who publishes this document

Ya Habibi is a trading name of DAPPER TRADING LTD, a company registered in England and Wales, company number 8800299. Registered office, which is also the address for service of any legal notice: Oak House, Reeds Crescent, Watford, WD24 4QP, United Kingdom. VAT number 190396586. Ya Habibi is part of the Webmasters LDN group, webmastersldn.com, which is also a trading name of the same company.

Contact: support@ya-habibi.co.uk, or in writing to the registered office above.

*Prepared 25 August 2026 for review by a qualified solicitor. Not legal advice.*