What Rin stores,
and what it sends.
Last updated 7 October 2026 · applies to Rin for iOS and Android
Rin is a habit planner made by Owais Khan. It is free and open-source, and this policy describes it as it is actually built. Every claim below corresponds to code you can read in the repository.
The short version
There are no accounts and no analytics. Everything you write stays on your device unless you switch on backup.
If you switch on backup, your months and deadlines are encrypted on your phone and the encrypted result is stored on Google Firebase, filed under an anonymous id. The key never leaves your phone, so neither Google nor the developer can read it. That is still data leaving your device, so this policy says so plainly rather than claiming nothing is collected.
This describes the app as built. Firebase's config files are not in the public repo, so a phone built from source has no backend to reach until you point it at a project of your own.
Who is responsible
Owais Khan, the sole developer, is the data controller for the small amount of data described below. There is no company, no team and no third party with access.
Contact: owais.develops@gmail.com, or open a GitHub issue if the question suits being asked in public.
What stays on your device
By default, and permanently if you never turn on backup, all of the following is stored only in the app's own local storage on your phone, and is deleted when you uninstall the app:
- your habits, and the marks you make against them each day;
- your deadlines, their dates and whether they are finished;
- your observations and key goals;
- your settings: the theme and which chart you prefer;
- the snapshot the home-screen widgets read, in a container shared with the app.
None of it is transmitted, and none of it is readable by the developer. There is no cloud copy of a device that has not enabled backup.
What is sent, and only if you enable backup
Backup is off until you turn it on, and the app is fully usable without it. Until you use it, the app sends nothing to the backup server or to the attestation services described below. When you do turn it on, or enter a code to restore one, three things happen.
1 · A device attestation
Before the app first contacts the backup server, Firebase App Check uses Apple's App Attest on iOS and the Play Integrity API on Android to confirm that the request comes from a genuine install of this app rather than a script, which is what stops the backup store being a free key-value database for anyone who read the repo. It involves Apple or Google under their own terms, and it carries nothing about you or your habits. It does reach Google, which sees your IP address.
2 · An anonymous sign-in
The app signs in to Firebase Authentication anonymously. This creates a throwaway identifier for the install. It is not an account: no name, no email address, no password, and nothing you have written is filed under it. Reinstalling produces a different one. It exists so that requests carry an attestation token and Firebase can apply its own rate limits.
3 · Encrypted records
Each month, and your list of deadlines, is encrypted on the phone with XChaCha20-Poly1305 using a key derived from a backup code that the app generates on your device and stores in the iOS Keychain or the Android Keystore. Only the resulting ciphertext is uploaded, filed under an id derived separately from the same code by HKDF-SHA256.
Because the id and the key come from different derivations, the id reveals nothing about the key. Anyone holding the entire database, whether Google, the developer or someone who got in, has a pile of unreadable ciphertext under opaque ids. The whole of the server side is 96 lines, and it is in the repository.
The backup code never leaves your phone. There is deliberately no recovery path: if you lose the code, the backup stays encrypted forever, and nobody, including the developer, can restore it for you. A way to reset it would be a way in.
What is never collected
- No analytics, telemetry, usage statistics or crash reporting.
- No advertising, no ad identifiers, no ad SDKs.
- No name, email address, phone number, or any other contact information.
- No contacts, calendar, photos, camera, microphone or location data. The app never requests these permissions.
- No persistent advertising or tracking identifier of any kind.
- No data is sold, shared or transferred to any third party for their own purposes.
Google Play Data Safety, in the same terms Google asks for
This is the honest mapping of the above onto Play's Data Safety questions.
| Question | Answer | Why |
|---|---|---|
| Does the app collect or share user data? | Yes, collect, if backup is enabled | Encrypted content leaves the device. Nothing is shared with third parties. |
| Data type | App activity: other user-generated content | Habits, marks, deadlines, notes and goals, as one encrypted blob. |
| Purpose | App functionality | Restoring your months onto a new phone. Nothing else. |
| Is collection optional? | Optional | Off by default; the app works fully without it. |
| Encrypted in transit? | Yes | HTTPS, and the payload is already end-to-end encrypted before it is sent. |
| Can users request deletion? | Yes | In the app: Settings → Backup → Delete the backup. Steps below. |
| Data used for tracking or advertising? | No | There are no ads and no tracking of any kind. |
| Account creation required? | No | There are no accounts at all. |
Processors
Only if backup is enabled, and only for the purposes above:
- Google (Firebase App Check) and Apple (App Attest) or Google Play (Play Integrity), for the device attestation described above.
- Google Firebase (Authentication, Firestore) stores the encrypted records and, like any hosted service, processes the connection metadata that reaching it necessarily involves, including your IP address, under Google's own privacy terms.
Nothing else. The app contains no other network code: the only file in the project that
touches a network is
src/sync.ts,
and its entire surface is nine functions, none of which will do anything without a backup
code.
Notifications
Habit nudges and deadline reminders are scheduled locally by your device. They are not push notifications, no server is involved, and no notification token is registered or sent anywhere.
Retention, and deleting your data
Local data lives until you delete it in the app or uninstall the app.
An encrypted backup is kept until you delete it, or until it is overwritten by a newer one from a device holding the same code. Nothing expires on a schedule, and nothing is kept back once you have deleted it.
Deleting your backup, in the app
- Open Rin and tap the settings control at the top right of the main screen.
- Scroll down to Backup.
- Tap Delete the backup.
- Read the confirmation and tap Delete.
Every encrypted record filed under your backup id is removed as you watch: each stored month and each stored list of deadlines. It is not recoverable afterwards, by you or by the developer, and no code will bring it back. If the connection drops part way the app tells you how many records went and offers to finish the job.
What is deleted, and what is not:
- Deleted: every encrypted month and every encrypted deadline list stored under your backup id, which is the whole of what the backup consists of.
- Kept: everything on your phone. Your habits, marks, deadlines, observations and settings are untouched. Deleting the backup is not deleting your months. To remove those, delete them in the app or uninstall it.
- Also kept: the anonymous sign-in identifier for the install, which has nothing filed under it once the records are gone and is discarded when you uninstall.
Deletion is immediate and is not staged or queued. Google may hold operational copies inside its own infrastructure for a short period under its own terms, as it does for any Firebase deletion; neither those copies nor the originals are readable without the code, which never left your phone.
Two other things are worth separating from the above, because they are easy to confuse with it:
- Forget the code, in the same Settings screen, removes the code from your phone and stops this device backing up. Your local data is untouched and the stored backup stays where it is, and anyone with the code written down can still restore it. This is the reversible one.
- Uninstalling removes everything local, and leaves any backup standing. Delete the backup first if you want it gone.
If you uninstalled without deleting first, reinstall Rin, enter your backup code on the backup screen, and the steps above become available again. That is the whole of the route, and it is deliberately the only one: the record is filed under an id derived from your code by a one-way function, the app never displays that id, and nothing stored alongside it names a person. There is no lookup the developer can run on your behalf.
Never send anyone your backup code, including the developer, and including in an email or issue asking for a deletion. The code is the decryption key; handing it over hands over the ability to read the backup. No genuine request for support will ever ask you for it. If you have lost the code, the record stays as ciphertext that nobody (you, Google, or the developer) can read, which is the intended end state rather than a gap in it. You are welcome to get in touch with any question about this.
Children
Rin is not directed at children and collects no personal information from anyone, of any age.
Your rights
Where the GDPR, the UK GDPR or similar laws apply, you have rights of access, correction, deletion, restriction and portability. In practice almost all of your data is already only on your own device and under your direct control; for an encrypted backup, the deletion route above is the mechanism. The lawful basis for processing an encrypted backup is your consent, given by switching backup on, and you may withdraw it at any time by turning it off.
Changes
If this policy changes, the date at the top changes with it, and the history of every change is in the commit log for this file, which is a more useful record than a paragraph promising to notify you.
This website
This site sets no cookies, runs no analytics and makes no third-party requests. The fonts are served from this origin. It stores one thing in your browser: whether you chose the dark or the light theme. The front page prints a live list of every request it has made, so this is checkable rather than merely stated.