Privacy Policy — AI features
This policy covers Review Diary (com.sskplay.a3diary,
Android), an app published by sskplay (“we”, “our”). Review Diary
can send a diary entry to an AI model to write a reflection on it, and it keeps a
small amount of data on a server we operate. Because of that it is not
covered by our general privacy policy, which describes apps
that keep everything on your device. Where the two differ, this page is the one that
applies to Review Diary.
Overview
Your diary lives on your phone. No diary text is sent anywhere until you ask for something that requires it, and there are exactly two such things:
- You ask for an AI reflection on one specific entry — that one entry is sent, through our server, to an AI model provider.
- You turn on encrypted backup — the text of your entries is encrypted on your phone with a key only you hold, and the encrypted result is uploaded. Two fields travel in the clear so the app can sort and show your entries: the date and the mood value. See Encrypted backup below.
If you do neither, no diary text ever leaves your device. Both are off until you act, and both can be stopped at any time.
Separately from your diary, the app does send us a small amount of data that is not diary content: an anonymous installation record, and any feedback you choose to send us from inside the app. Those are listed in full under What we keep on our server below.
Separately again, the app reports crashes and usage analytics to Google, and the free version shows banner ads. Neither carries your diary: see Crash reports and usage analytics and Advertising below.
AI reflections — what is sent
When you explicitly request a reflection on a diary entry:
- Only that one entry is sent. Your other entries stay on the device. There is no bulk upload and no background sync of diary text.
- The request goes to our own gateway at
a1.sskplay.com, which forwards it to an AI model provider. We use more than one provider upstream, and which one handles a given request may change. - The model is not told who you are. Your name, email address, and account are not part of the request. What reaches the model is the entry text, the mood value you picked, the date, and the language.
- Where a reflection refers back to how you have been writing lately, it is not your earlier entries that are sent — only a short summary of writing style, on the order of 30 characters.
- To enforce the free monthly limit we keep a per-installation monthly counter of how many reflections have been requested. It counts requests; it does not record what they were about.
The entry passes through our server in order to reach the model, and the app tells you so before you use the feature: “Your entry is stored on our server and reviewed by AI.” Today, once the reflection has been returned, we do not keep the entry text in our database. Treat the in-app notice as the promise we are held to: if that ever stops being true, this page and the in-app notice change together, and neither will ever claim less handling than actually happens.
When a request fails
If a request to an AI provider fails, our gateway writes an error log that can include part of the request and part of the response — up to 900 characters, kept for up to 90 days, then deleted.
This is not a hypothetical: some providers echo the content of a request back in their error response, so on a failed reflection a fragment of your entry can end up in that log. The logs are used only to diagnose failures. They are not read for any other purpose, not linked to a name or email address, and not shared.
Model training
We do not use your diary entries to train any model of our own, and we require our AI providers not to use them for training either. We want to be exact about the limit of that promise: once a request leaves our gateway, this depends on the provider honouring its own terms. It is a contractual commitment we hold them to, not something we can technically enforce or independently verify.
What we keep on our server
Our server runs on Cloudflare, and the database is Cloudflare D1. Your diary text is not in it. What is:
- A random installation identifier, generated on your device. It is not the Android Advertising ID, not the Firebase app instance ID, and not derived from any device or account identifier — three different values with three different purposes. Reinstalling the app produces a new one.
- Device model, OS version, app version, and language.
- Feedback text you send from inside the app. Before it is stored, we automatically mask email addresses, phone numbers, national ID numbers, card numbers, and URLs.
- Your subscription status and the purchase token that proves it.
- If, and only if, you sign in to use backup: a one-way hash of your Google account email address. The address itself is not stored, and the hash cannot be turned back into it.
Encrypted backup (optional, paid, off by default)
Backup exists so a diary survives a lost or replaced phone. It is off until you turn it on.
- You choose a passphrase. A key is derived from it on your device (PBKDF2, 210,000 iterations) and the text of your entries is encrypted with it (AES-GCM) before anything is uploaded.
- The key and the passphrase never leave your device. We cannot read the text of your entries, and neither can Google. What we hold for those is ciphertext.
- Two fields are stored in the clear so the app can sort and display your entries without decrypting everything: the date and the mood value. The entry text is never in the clear.
- If you forget the passphrase, nobody can recover the backup — not you, not us. There is no reset, because there is no copy of the key.
- Turning backup off offers to delete the cloud copy.
Google sign-in is used for backup and nothing else. It is what lets a restore on a new phone find the backup that belongs to you; without an account there is no way to identify a backup as yours after the old device is gone. Signing in is only required if you use backup.
Crash reports and usage analytics
The app includes Firebase Crashlytics and Firebase Analytics, both from Google. They tell us when the app breaks and which parts of it people actually use.
- Crashlytics, when the app crashes: the stack trace, the device model, the OS and app version, and the state the app was in just before. Nothing is collected from debug builds.
- Analytics: which screens you opened and which actions you took — saving an entry, requesting a reflection, opening the paywall, starting a purchase — along with an app instance ID assigned by Google and general signals such as device, region, and language.
Both are processed by Google under the Google Privacy Policy. You can turn either one off on its own, under ⋮ > Privacy in the app. They start on, your choice is remembered between launches, and switching either off costs you no features at all.
No diary content is attached to any of these events, and that is enforced in the code rather than left to care: titles, entry text, and reflection results are never passed as event parameters, and even the length of a piece of writing is reported as a bucket (short, medium, long) rather than an exact count, because an exact character count is itself information about what you wrote. A source check fails the build if an analytics call so much as references an entry or title variable.
One honest exception: a crash report can contain a fragment of what you typed, because an exception message can carry the input that caused it. We cannot rule that out, so we would rather say it than let you assume otherwise.
Advertising (free version)
The free version of Review Diary shows banner ads provided by Google AdMob (Google LLC). Subscribing to premium removes them.
The ads and your diary are kept apart, and we want to be specific about what that means rather than leaving it to be inferred:
- Ads appear on the list screen only. There is no ad on the screen where you write an entry, and none on the AI reflection screen.
- The list shows each entry's title, or its first line when you did not give it a title, so a short excerpt of an entry can be visible on the same screen as an ad. That excerpt never leaves your device: it is not sent to the ad network, the ads SDK cannot read it, and it plays no part in which ad you see.
- Your diary is not used to target ads. No entry, and nothing derived from one, is sent to an ad network. The ads SDK cannot reach your diary, and what you write plays no part in which ad you are shown.
What Google may use to choose an ad is its own signals, not ours: the device's advertising ID, approximate location derived from your IP address, and coarse device information such as model, OS version, and language. That is Google's processing, governed by the Google Privacy Policy and AdMob's ads personalisation policy. On Android you can reset or delete the advertising ID, and opt out of ad personalisation, in Settings > Privacy > Ads.
In the EEA, the UK, and Switzerland, Google's UMP consent form is shown first, and no ad is requested until you have answered it. You can reopen that form from inside the app at any time and change what you chose.
What we do not do
- We never send your diary — or anything derived from it — to an ad network. The free version shows ads, and they are chosen without any input from what you wrote; see Advertising above.
- We do not build a profile of you from your diary, and we do not sell or share one. What we do use is Google's own tooling, and we would rather name its reach than round it down: Firebase Analytics records what you do in the app against an app instance ID Google assigns; ad personalisation through the advertising ID does work across apps. Both are described above, under Crash reports and usage analytics and Advertising. You can switch ad personalisation off in Android's settings, and premium removes the ads entirely.
- We do not sell your data, and we do not share it with third parties beyond the service providers listed below, each of which only receives what it needs to do its job.
- We do not read your diary. It is not in our database, and the model receives it without knowing whose it is. There are exactly two places a fragment of an entry can end up somewhere we could open it, and both are diagnostic: the gateway error log after a failed request, and a crash report. We look at those to fix failures, and for nothing else.
Service providers
- Cloudflare — hosts our server and the D1 database, and the
a1.sskplay.comgateway. Cloudflare Privacy Policy - Google — Google Play Billing for the subscription, Firebase Authentication for backup sign-in, Firestore for the encrypted backup data, and Firebase Crashlytics and Firebase Analytics for crash reports and usage analytics. Google Privacy Policy
- Google AdMob — serves the banner ads in the free version. It receives the advertising signals described under Advertising, and no diary content. How Google uses information from sites or apps that use our services
- AI model providers, reached only through our gateway, and only for a reflection you asked for. They receive the entry text, mood, date, and language — never your identity.
In-app purchases
The subscription is handled by Google Play Billing. Google receives and processes the payment — we never receive or store your payment details. We keep only the purchase token and whether the subscription is active, so the app knows what you are entitled to.
Children's privacy
Review Diary is not directed to children under 13, and we do not knowingly collect personal information from them. If you believe a child has used the app and sent us data, contact us and we will delete it.
Retention and deletion
- On-device diary data is kept until you delete an entry, clear the app's data in Settings > Apps, or uninstall the app.
- Diary text sent for a reflection is not retained in our database after the reflection is returned. The one exception is the gateway error log described above: up to 900 characters, up to 90 days.
- Encrypted backup is retained until you turn backup off (which offers to delete the cloud copy) or ask us to delete it.
- Installation record, feedback, and subscription status are retained while the app is in use, and deleted on request.
- Payment data is retained by Google under its own policies, as are the advertising data AdMob collects in the free version and the crash reports and analytics events sent to Firebase.
How to ask us to delete your data
Email contact@sskplay.com with your installation ID, which is what identifies your records to us. You can find it by tapping the title on the diary screen seven times. We respond within 30 days.
Your choices
- Do not request a reflection, and no diary text is transmitted at all.
- Leave backup off, and no diary is uploaded. The installation record described above is sent either way, and feedback is sent only when you write some.
- Turn crash reports or usage analytics off, individually, under ⋮ > Privacy in the app. Both start on, your choice is remembered, and turning either off takes nothing away — every feature works exactly the same.
- Subscribe to premium, and the ads go away. In the EEA, the UK, and Switzerland you can also reopen Google's consent form from inside the app and change your advertising choices at any time.
- Turn backup off later, and delete the cloud copy when prompted.
- Uninstall, and the on-device diary goes with it. Server-side records are deleted on request as described above.
Changes to this policy
We may update this policy. When we do, we will update the “Last updated” date at the top of this page. Because this page is also the basis of our Google Play Data safety declaration, any change to how the app actually behaves is reflected here, in the in-app notice, and in that declaration together.
Contact
- Developer: sskplay
- Email: contact@sskplay.com
- Website: apps.sskplay.com
- General privacy policy (other apps): apps.sskplay.com/privacy