Privacy policy

Self-reviewed · last updated 2026-10-09. Written by us from what the app actually does; not reviewed by a lawyer.

This policy explains how the Rakshak app handles personal data. It is published by Exadatum Software Services Private Limited ("we", "us"), CIN U72900PN2016PTC158545, Flat No. C-1003, 33 Keshav Kunj, Nr. Old Orbis School, Manjari Rd, Pune, Maharashtra 411036, India. It describes what the app does today, not plans; where something is planned we say so.

The short version

• Your data stays on your phone. Typing, contacts, call history, messages, photos and SOS settings are processed on the phone.
• We receive nothing from the app. We run no server for the app, and it contains no analytics, advertising or tracking code. We see only what you send us yourself, such as an email.
• AI requests go to the AI service you choose, only when you use an AI feature, with card numbers, Aadhaar, PAN, one-time codes, secret keys and words you mark as private replaced before sending.
• SOS sends what you set up, to the people you chose, through your own phone's SMS.
• No selling, no ads profiling. There is nothing to sell: we do not have your data.

What stays on your phone

What leaves your phone, and to whom

The privacy engine in the app checks every AI request before anything is sent: it blocks requests from password and other secure fields, from apps that ask for no learning, and when no provider is set up. Each request is listed in Settings → Activity with the provider and the amount sent, never the text.

Your AI provider is chosen and paid by you. We do not see those requests or the replies. Read the provider's privacy policy, and delete data there if you want it removed.

What we receive

• From the app: nothing. There are no app accounts yet, no server and no analytics.
• From Google Play: the counts and crash reports Google shares with every developer, if you allow your phone to share them. They do not identify you to us.
• From you: emails you send to support or the grievance officer. We keep them as long as needed to answer and to meet legal duties, then delete them.

Features that need a shared service (verified caller badges, public profiles, who viewed me) are demonstrations today: they show sample data and send nothing. The "Our model" AI provider is also a demonstration on the phone until our AI service exists.

Permissions

The app asks for each Android permission when a feature needs it, and works without the ones you refuse. SMS, call log and location are used for SOS, caller protection and the optional messages app; the microphone for voice typing and voice SOS; the camera for SOS photos and stickers; notification access only for replying to chat notifications and sorting messages when you turn those on. Nothing a permission gives the app is uploaded to us.

How long data is kept

Your rights

Under India's Digital Personal Data Protection Act, 2023 you can ask us for a summary of personal data we hold about you, to correct or erase it, to withdraw consent, and to nominate someone to act for you. Because the app keeps your data on your phone, you can do most of this yourself: see Delete your data. For anything we hold (such as your emails), write to the grievance officer. If you are not satisfied with our answer, you may complain to the Data Protection Board of India.

Children

The app is not designed for children. Public profiles, when they exist, will be for adults only. We do not knowingly receive children's data; we receive no data from the app at all.

Security

Data the app keeps is in its private storage; sensitive items (SOS evidence, the message index, pairing secrets) are encrypted with a key held in the Android Keystore. AI requests use HTTPS. Logs and crash reports never contain what you type, your messages or your photos.

When a cloud service starts

A small cloud service, hosted in India, is planned for accounts, push notifications and an SOS that keeps alerting your contacts if your phone dies. It is not running yet. Before it starts we will update this policy, say what it stores and for how long, and the app will ask before using it.

Changes

When this policy changes we update the date at the top of this page and, for important changes, tell you in the app.

Contact

Questions: abshingate@exadatum.com. Complaints: the grievance officer.

How each feature handles your data

The details below are the app's own privacy design, kept in the app's source and copied here every time this site is built, so they always match the app.

Privacy engine

Every AI request passes the privacy engine in the shared core before any network call (ADR-0003). Providers are internal to the core; KeyboardAi.run is the only way in.

Decisions, in order

Speech requests (Speech.stt / Speech.tts, used by the call assistant) go through the same engine: audio for speech-to-text cannot be redacted, so it leaves only when the network is allowed and a provider is set (checks 3–4); text for text-to-speech gets checks 3–7. A blocked request raises SpeechBlockedException and nothing is sent.

Only the text the operation works on is sent: the selection, else the field, else — for operations the user started on a copied message — the clipboard. Keystroke history is never kept or sent.

Redaction

Detected values are replaced by placeholders such as ⟦CARD_NUMBER_1⟧ before sending. The model is told to keep placeholders, and the core puts the original values back into the answer, so a rewrite keeps the real number while the provider never sees it. The AI bar shows what was hidden.

Sentence completion

Story #115, under the owner's direction that privacy is built in deeply (2026-10-09).

• On the phone by default. Suggest the rest of the sentence uses the phone's own model (Gemini Nano or the downloaded model on Android, Apple Intelligence on iOS); nothing leaves the phone.
• The service only when turned on. Use my AI service when the phone can't is off until the user turns it on. Its switch says plainly what is sent (the sentence being typed, with personal details replaced) and to which provider. On iOS it also needs Full Access.
• Through the privacy engine. Every service request passes PrivacyEngine.evaluateCompletion: placeholders for card numbers, codes, Aadhaar, PAN, keys and private terms, restored only in the suggestion; blocked when sensitive content must not be sent.
• In Activity, without text. Each request is listed as Finish sentence with the provider, model, characters sent and what was hidden; never the text.
• Never logged. Typed text and suggestions are not written to logs or crash reports.
• Kept only while open. Suggestions are cached in memory and cleared whenever the keyboard closes; nothing is stored.
• Never in private fields. Not in password, incognito or no-learning fields.

Prompt history

The prompts used to create stickers and memes are kept in the app's own files (Android) or the app group (iOS), so they can be copied and reused (#155). They are never sent anywhere. A reused prompt is a new request and passes the privacy engine like any other. Keep prompt history in Privacy turns the history off; it is on by default, and Settings → Activity can delete one prompt or clear them all.

Call notes

The app never records a call (#172). A recording the user made with the phone's own recorder is copied into the app's private files (Android) or the app group (iOS) when the user adds or shares it, with who was on the call as the user typed it, shown on every note. Transcribe on this phone uses the platform's on-device recogniser and sends nothing. Transcribe with the user's AI service sends the audio only on that tap; the privacy engine checks the network and the provider first, and the request appears in Activity. The transcript passes the privacy engine like typed text before notes are made, with details such as card numbers hidden and put back; with no service, offline, or when the privacy settings block a private detail, the notes are made on the phone instead and say so. Reminders open the calendar app with the event filled in; nothing is saved without the user confirming there. Deleting a note deletes the app's copy of the recording after the Undo window; the recorder app's own copy is the user's to delete.

Caller directory and badges

Verified and Premium badges come from an opt-in directory in the account service (ADR-0009, API). It holds only members who proved their number with a one-time code and turned on Show my verified badge in Settings → Caller badge. Contact books are never uploaded: looking up a number sends that one number and nothing else, and lookups are not kept against the person who asked. Turning the badge off unlists the number at once; Delete my directory data removes the listing and the verification. The one-time code is read with SMS autofill (Android) or one-time-code autofill (iOS), so the app never needs permission to read messages. A badge never softens a warning: when the phone's call risk or Scam Shield says a call or message looks like a scam, the badge is hidden and the card says so. Until the service exists the directory is a demo that sends no SMS and shows a Demo mark.

SOS persistence and acknowledgements

While SOS runs, the phone keeps a small record of it (the name and contacts it alerts, which escalation steps ran and who acknowledged) in device-protected storage, so a restart can resume it; it is deleted the moment SOS ends. To recognise an acknowledgement, incoming texts are checked only while SOS runs and only for a plain reply (OK, on my way, coming, ठीक है…) from an SOS contact; nothing else is read, kept or sent.

Profiles, viewers and contact requests

Public profiles build on the directory (ADR-0010, API). A profile is off until the member turns it on, needs a verified number and an 18+ declaration, and is never allowed on a phone linked as a child's. For members with a profile, the service keeps who looked them up for 30 days — this is the one place lookups are kept against the person asking, and only within these limits: a viewer is named only if they turned on Let people see that I viewed them, otherwise they are a count; Incognito (Premium) leaves no view at all and, while on, hides the member's own viewers too; lookups are limited to 20 a day (100 on Premium). Contact requests share only the email the member chose to add, and only after they approve; a decline stops new requests for 30 days and a block is permanent. Export my data lists every lookup made, every view left and received and every request; Delete my profile data erases them. Nothing is sold or used for ads. Until the service exists this is a demo with example viewers.

Face photos and personal greetings

Personal greetings (#183) are built so the user can trust them with photos of the people closest to them:

• On this phone. Face photos, who is who and their consent live in the app's private storage (Android) or the app's own container, excluded from backup (iOS). The app has no backup of them and neither do we. Each photo is re-encoded on the way in, which drops its location and camera details.
• Sent only for one request the user starts. Sticker, Card and Meme are drawn on the phone and send nothing. Caricature, Cartoon and Photo send the chosen photos (at most four, at most 768 px) to the user's image provider for that one request, after a disclosure that names the provider and the people: "Photos of Priya and you will be sent to OpenAI to make this; nothing is kept by us." The user's words pass the privacy engine like any request. Providers that can't work from photos are never sent them.
• Their permission. Another person's photos can be added only after the user confirms that person agreed, once per person. Take back in Settings → Privacy → Face photos withdraws it and deletes that person's photos from the app. Delete all face photos removes every face photo and who is who at once.
• No faces in logs. Activity records "Greeting · 2 photos · OpenAI" (or "your AI service at <host>" for the user's own service) and the model; never names, files or pictures. Crash and debug logs carry nothing about the photos.
• Results stay with the user. Greetings are saved in the Personal sticker pack on the phone and leave it only when the user sends them.
• Safety. Public figures and sexual, violent, humiliating or deceptive ideas are refused on the phone before anything is sent; the provider's own safety filters stay on.
• Marked as AI. Pictures made with AI carry the IPTC digital source type trainedAlgorithmicMedia in the file; realistic ones also show a small "Made with AI" mark. A signed C2PA manifest is not added (it needs a signing certificate).

Post studio

The Post studio (#201) writes posts for many platforms from the person's words, photos and videos:

• Media stay on the phone. Picked photos and videos are copied into the app's private storage with the draft, are not backed up and are deleted with the draft. Crops, colour looks, subtitles and music are made on the phone (Android drawing and Media3 Transformer); nothing about the pictures is sent to make them.
• Words through the privacy engine. Write posts sends only what the person typed (and the photo description they accepted) to their AI provider, with card numbers, Aadhaar and other details replaced first and put back after; the phone's own model is used first when it is ready. Without a provider the versions are written on the phone.
• A photo only after asking. Describe my photo with AI sends one photo, at most 1,024 px, only after a dialog naming who receives it ("your AI service at <host>", "OpenAI"); the description comes back for the person to edit.
• Subtitles heard on the phone. Speech in a video becomes subtitles with the phone's own recogniser; the audio is never sent.
• No content in logs. Activity records "Post · 4 platforms" or "Post · 1 picture", the provider and the model — never the words or the pictures.
• Sharing is the person's tap. Posts go to another app through the share sheet; the studio never posts by itself. Exported files for sharing are deleted after a day.

SOS photos and sound

SOS can take one photo with each camera and record 5 seconds of sound (#184). It is off until the person turns it on in SOS settings, where the page says what is captured and who receives it. Nothing is captured in practice. A real SOS or a test run sends the photos and sound only to the person's own SOS contacts: as a picture message from the phone, or as a link from the person's own evidence service when it exists, never through a project server. Copies stay on the phone, encrypted with a key in the Android Keystore (iPhone: iOS file protection), and are deleted after 30 days unless the person keeps them; Delete all removes them at once. Logs and the SOS status show only what was taken and how it was delivered, never the images or sound.

App lock

The app lock (#194) is off until the person turns it on (Settings → Privacy → App lock; the Settings list offers it once). It opens the app with the phone's fingerprint, face or screen lock (Android BiometricPrompt, strong biometrics or the device credential; iOS Face ID, Touch ID or passcode), or an app PIN. The biometric data never reaches the app: the system only reports whether it matched. The app PIN is stored as a salted SHA-256 hash, never as the digits, and wrong tries back off from 30 seconds up to 15 minutes. While the lock is on, the recent-apps preview is blank and the keyboard's clipboard history asks to unlock first; typing is never locked. Turning the lock off or changing the PIN asks to unlock first.

SOS is never behind the lock. The SOS screen (countdown, running SOS and stopping it with the SOS PIN), a contact's incoming SOS alarm, Scam Shield's stop screen, a ghost call, call-time and keyboard flows open without unlocking; the lock screen itself has an SOS button. The exempt screens are one list in the shared core (AppLock.EXEMPT), and a test fails if any SOS screen is missing from it.

SOS pairing and alarms on contacts' phones

Pairing an SOS contact who has the app (#189) creates a random 20-byte secret, shown once as a QR code (or a text code the person sends themselves) and stored on both phones encrypted with an Android Keystore key. It never leaves the two phones; there is no server. SOS texts to a paired contact carry one extra line: the kind of message, whether it is a test run, a run id, a counter, the time, the location and battery that the readable text already contains, and a signature. Their phone acts on it only if the signature matches the pair's secret and the counter is new, so a forwarded, edited or faked text is ignored (logged as "ignored", never with its content). The contact's phone replies automatically when the alarm rings and when they tap I'm on it; the pairing screen says so before they pair. Removing a pair deletes its secret on that phone. A plain "OK" reply from an SOS contact during SOS is counted as an acknowledgement; no other incoming text is read for SOS.

Messages app

The optional messages app (#197) works only after the person picks Rakshak as their SMS app on a screen that says what changes, including that RCS chat features are not available to other apps. Texts are read from and written to the phone's own message store and nowhere else: nothing is copied to the app's storage or sent to a server, and switching back to another messages app keeps every conversation. Scam warnings in a conversation are worked out on the phone (Scam Shield). Notifications show only "New message" on the lock screen. Logs never contain a message, a number or a name. The carrier's notice for a picture message (a download address, no picture) is kept privately for 7 days so the MMS update can fetch it (#198).

Calls and messages by category

Calls by category (#196) reads the phone's call history (call log permission, already used by caller protection) and, with the contacts permission, names, contact groups and starred contacts; everything is worked out on the phone and nothing is uploaded. Messages by category is off until the person turns it on. It then keeps the messages that arrive afterwards (from SMS, read directly with the SMS permission, and from chat apps' notifications) in an index encrypted with the Keystore key, for 90 days by default (30 days or 1 year to choose); starred messages stay until un-starred. Delete all messages removes the index at once; turning sorting off stops new messages being kept. The person's own category for a sender and the favourites are kept as plain settings because they hold no message text. No message text appears in logs, crash reports or Activity. The app never reads older or sent messages and never asks for READ_SMS.

Starting SOS from a trusted person

The trusted-person list and the code word (#190) stay on the phone; the code word is kept only as a salted SHA-256 hash. Only an SMS counts, because it carries the sender's number; chat apps show only a display name, so a WhatsApp, Telegram or Signal message with the code word never starts SOS and is dropped unread. An SMS counts only when it comes from a trusted person and contains the code word as a whole word; nothing else in it is used, SOS goes only to the phone's own SOS contacts, and such a message is never sorted, indexed or kept, so the code word is stored nowhere. Every request, accepted or refused, is kept on the phone (newest 200) and shown on the settings page, and the person is reminded monthly who can start SOS; a refused code word from an untrusted number raises a notice. On a child's phone, a guardian's location check is answered by a text with the map link and is always shown on the child's phone; a teenager can pause location checks, never an emergency. Changing the list or the code word needs the Stop PIN.

Our model with your account

Signed in (ADR-0011), the app reaches our AI service with a token from the backend instead of a key (#214). The token holds the account id (a random id, never the phone number or name), the issuer, the audience and an expiry ten minutes after it is issued; nothing about what is typed. It is kept in memory only and dropped on sign-out. The AI gateway uses the account id to count the day's allowance. The privacy engine still decides what each request may contain before it is sent; the token changes only who is asking. Signed out, or with another provider, the entered key is used.

Report and recover

Fraud cases (#204) stay on the phone. A case's details (what happened, suspect numbers, payment details read from a bank SMS the person pasted, complaint numbers) are stored encrypted with an Android Keystore key; screenshots are copied into the app's private storage and encrypted with their own Keystore key. Nothing is uploaded. The complaint pack (PDF and ZIP) is built in the app's cache when the person taps Share and leaves the phone only through the share sheet they choose. Copied fields are marked sensitive, so Android 13+ hides them in the clipboard preview. Payment parsing keeps only the last four digits of an account. Follow-up reminders say what to do, never what the fraud was. The app never submits a complaint and never contacts a bank, the police or a portal on the person's behalf. Delete this case and Delete all cases remove everything, screenshots included.