Inklune Privacy Policy
- Applies to: the Inklune iOS and Android app
- Published at:
https://inklune-legal.blackpet.workers.dev/en/privacy - Read alongside: Terms of Service
https://inklune-legal.blackpet.workers.dev/en/terms - Authoritative text: The Korean version at
https://inklune-legal.blackpet.workers.dev/privacyis authoritative. This English version is provided to aid understanding. - Last updated: 2026-09-15
Inklune is an app that keeps your journal on your device. The text, photos, and location of an entry are stored as files on your device, and they do not leave the device unless you send them yourself. This document sets out what nevertheless leaves the device, why it leaves, and how to turn it off.
Two kinds of content are mixed together in this policy. The earlier part covers information the app handles as a whole, and the later part (from ## What is collected onward) covers one thing only: error reporting (diagnostics). The diagnostics part is checked automatically against the transmission allowlist in the app's code, so if the code changes and this document does not, or the other way round, a check fails during development.
Local entries — they stay on your device
The body text, title, tags, photos, location, and step count of an entry are stored in files and a database on your device. They are not sent to our servers, and no backup service is switched on automatically. If you have turned on your device's system backup (iCloud or Google backup), they may be included in that backup, and Apple and Google handle that backup under their own policies.
Files created by export and files read by import are also handled only on the device.
Exchange letters — delivered in a form whose content cannot be read
When you use the exchange diary, letters pass through our relay server on the way to the other person.
- Letters are encrypted on your device and can be opened only on the other person's device (end-to-end encryption). The server holds no key and cannot read the content. Photos attached to a letter are encrypted and delivered in the same way.
- What remains on the server is the encrypted blob and the minimum information needed for delivery (the room id, an anonymous identity id, the size, and the time).
- The server keeps a letter for 30 days by default. If the other person picks it up sooner it is deleted at that point, and, the other way around, each time the other person opens their mailbox, the remaining period is extended back to 30 days. However often it is extended, it can never go past 33 days from upload, and the storage system's own deletion rule removes whatever is left once 35 days have passed.
- Invites are an exception. The room name, emoji, and color attached when an invite is created are stored on the server unencrypted. The server has to hand those values over so that the other person, on opening the invite, can see what they are joining. It is better not to put anything in a room name that you would not want known.
- The token in an invite link expires after 24 hours by default (7 days at the most, if a longer period is set), and a record of the invite may remain on the server for some time even after it has expired or been used.
- The relay server and the diagnostics server described below run on Cloudflare's services (Workers and R2 storage). In other words, our storage and transmission infrastructure is entrusted to Cloudflare.
- You are identified only by a key pair your device creates, with no name, email address, or phone number. There is no sign-up and no account.
Notifications
To receive a notification about a new letter, the push token issued by your device has to be kept on the relay server. This applies to both iOS and Android. The token is used only for sending notifications, and it is no longer used once you turn notifications off or delete the app.
Google's FCM (Firebase Cloud Messaging) is used to deliver notifications. On both iOS and Android the token is issued by Google Firebase, and on iOS, FCM then passes the notification to the device by way of Apple's APNs. In the course of this, Google and Apple handle device and app installation information under their own policies. Notifications carry no letter content; they carry only the room id and the kind of event (a new letter, connected, and so on), which says no more than what happened in which room.
Maps and place names
When you attach a location to an entry or look at the map, coordinates go to the two places below. They do not go to our servers, and we do not store them either.
- Map imagery: the map is drawn by the Google Maps SDK built into the app. To draw the map, the SDK fetches the data it needs from Google's servers, and the coordinates of the area you are viewing are passed to Google at that point. Use of Google Maps is also governed by Google's privacy policy (
https://policies.google.com/privacy). - Place names: turning coordinates into a name such as "Jongno-gu, Seoul" is handled by the geocoding feature of the device operating system (Apple or Google). The coordinates are passed to that operating system vendor at that point.
In both cases the only thing that leaves an entry is the coordinates, and the text, photos, and title of the entry do not go with them. Requests that travel over the internet do, however, carry more than the coordinates: they also carry information that comes with the connection itself (the IP address, the type and version number of the device, the app, and the SDK, and so on), and that information is handled by Google and by the device operating system vendor under their own policies. If you do not open the map screen and do not attach a location, no coordinates leave.
Permissions
The permissions the app asks for are used only as far as writing a diary requires. The data in the table below is stored on the device, and the only cases in which it leaves the device are the ones described in the Maps and place names section above, and exchange letters.
| Permission | Where it is used |
|---|---|
| Photos and camera | Attaching a photo to an entry (on the device) |
| Location | Attaching the day's place to an entry and showing it on the map (for map and place name lookups, see the section above) |
| Activity and health (step count) | Attaching the day's step count to an entry (on the device) |
| Notifications | New letter notifications |
| Face ID and biometrics | App lock (on the device) |
AI keys
You can register your own key for an AI service. The key is kept in the device's secure storage, is never displayed on screen again, and is not transmitted to our servers. In the current version the key is only stored, and entry content is not sent to any AI service.
Payment
Paid features (Inklune Pro) can be bought inside the app — through the App Store on iPhone and through Google Play on Android.
- On the App Store, payment is handled by Apple. The payment method, card number, billing address, and receipt are received by the App Store, and we receive none of them. We have no list of App Store buyers either, so we do not know who has bought anything on iPhone.
- On Google Play, Google processes the payment. The payment method, card number, and billing address are received by the Google Play billing system, and we do not receive them. For Google Play sales, however, we are the seller, so in Play Console we can see the order records Google shows to sellers (order number, product, amount, order status, country of purchase, and the like) and can look an order up by the buyer's email address. Those records are not sent by the app; Google keeps them in the developer account, and we use them only to handle refunds and inquiries and to meet legal obligations such as tax filing. Where a law requires transaction records to be preserved (such as the Korean Act on Consumer Protection in Electronic Commerce), we follow that obligation for the period it sets.
The only thing the app stores is whether a purchase was made, and that value stays on the device — it is not sent to our servers.
One thing does leave, however. When a payment or a purchase restore fails, and the error reporting (diagnostics) described below is turned on, the classification name of the point that failed (a value beginning with tier.) goes to the diagnostics server. No payment method, receipt, or amount is included there, and there is no separate field for whether a purchase was made. The classification name can, however, reveal that a purchase took place — if the failure happened after the payment went through, while recording Pro on the device, that name alone shows that the store account on that installation has a purchase, and a failure while finishing the transaction shows that there may have been one (the same name is sent when a cancelled or failed transaction is being finished). The report itself carries no name or email, and its only identifier is a random value the device created at install time. We do not match or combine diagnostic reports with Google Play order records. What goes with it is exactly what the ## What is collected table below lists, and this reporting can be turned off in settings.
Information processed in the course of an App Store payment follows Apple's policy, and information processed in the course of a Google Play payment follows Google's policy. For App Store purchases, refund requests are received and reviewed by Apple. For Google Play purchases, you can ask Google or us for a refund.
Error reporting (diagnostics)
When the app crashes or a feature fails silently, a short report is sent to our server telling us what failed and where. It is on by default, and it can be turned off in settings. The table below is everything that is sent at that point.
What is collected
| Field | What it means | Example |
|---|---|---|
schema | The version number of the report format | 1 |
installId | A random id the device creates at install time. It is unrelated to any sign-in, email address, or advertising id, and it disappears when the app is deleted | 01J9Z... |
occurredAt | The time at which the error occurred | 2026-08-12T01:02:03Z |
kind | Whether the app crashed or a feature failed | crash / handled |
code | The classification name of the failure (a classification key, not the raw text of an exception) | invite.create.notRegistered |
httpStatus | The response number when a server refused the request | 503 |
frames | Only the function names at the point where the error occurred. There are no arguments, file paths, or line numbers | ["PairingService.createInvite"] |
appVersion | The app version | 1.0.0+1 |
platform | The kind of operating system | ios / android |
osVersion | The operating system version | 26.6 |
locale | The language setting (for reproducing bugs to do with dates and wording) | ko |
attempted | The number of items the app set out to process | 2568 |
succeeded | The number of those that succeeded | 8 |
attempted and succeeded are numbers that carry counts alone. For example, if importing entries from another app mostly fails, the only thing passed along is the pair of numbers meaning "2568 attempted, 8 succeeded". The content, titles, and file names of entries are not sent. The reason these numbers are included is that, without a count, one skipped entry and the loss of nearly everything look like the same single event, and a serious breakage would go unnoticed.
What is not sent
An error report contains none of the following, under any circumstances.
- The body text, title, or tags of an entry
- The names and file paths of photos and files
- Exchange tokens, invite links, or room names
- Identity keys (the cryptographic keys) and identity ids
- The raw text of an exception — sentences from an entry easily find their way into error text. The whole of that text is therefore left out, and only the type name of the exception is folded into the classification key.
- Names, email addresses, and phone numbers, including user names
- Any use of an IP address as a user identifier
What is sent is only the items listed in the ## What is collected table above, and the app is built so that it can carry only the items in that table.
Retention period
An error report is kept in storage for 30 days and is then deleted automatically. This period is enforced by the storage system's expiry rule.
Where it is sent
- The only recipient is the diagnostics server we operate ourselves (
inklore-errors). - It is not provided or sold to third parties, and no external analytics or advertising tools are used.
- Transmission is encrypted with HTTPS.
- Reports travel in one direction only, from the app to the server. The server does not issue instructions to the app or change the app's settings.
- It is not used for advertising, marketing, or analysis of usage behavior. The only use is the repair of breakage.
How to turn it off
Open the app's Settings screen and turn off the Send error reports switch under Diagnostics at the bottom; transmission stops at that instant.
- This feature is on by default. Most breakage is found through these reports before a user tells us about it, and that is why this table discloses what is sent.
- Once it is off, error reports are not sent. The other features of the app work as before.
- Reports that had piled up on the device without being sent are also deleted the moment you turn it off. Nothing that was held back while the internet was unavailable goes out later. If you turn it back on, reporting resumes from errors that occur after that point — what has already been deleted does not return.
- Reports that have already been sent are anonymous, so they cannot be traced to a particular user. They are, in any case, all deleted within 30 days under the retention period above.
Children's personal information
Inklune is not an app directed at children, and it does not knowingly collect children's personal information.
Changes to this policy
If what is collected changes, this document is amended along with it. The diagnostics part is checked automatically against the app's code, so adding items without amending this document is blocked during development.
Contact
blackpet@gmail.com