Privacy Policy

Effective 2026-11-04

1. General

Hidden Vowels (오늘의 초성) runs the same server behind the web app (chosung.dosaem.com) and the iOS and Android apps. This policy covers all three and is published under Article 30 of the Korean Personal Information Protection Act (PIPA).

There is no sign-up. Your records belong to a single guest token stored on your device. We never ask for your name, phone number, address, date of birth, or payment details.

We do not create or process pseudonymised data (PIPA Art. 28-2), and we make no automated decisions or profiling that affect you based on personal data alone (Art. 37-2) — neither applies to this service.

2. Why we process your data

• Running the puzzle, your streak, the leaderboard, and statistics
• Linking an account so the same records follow you across devices
• Checking your ad-free subscription status
• Serving ads in the apps (not to subscribers)
• Responding to incidents and improving the service

We do not use the data for anything beyond the purposes above, and we never sell it to third parties for advertising or marketing. If the purposes change we update this policy and its effective date.

3. What we collect, and how long we keep it

Guest token

A random string that identifies your records. It is a random value that carries no personal identifiers such as your name or email, and it exists so that your records continue without sign-up or sign-in. The server issues it on your first visit or first launch and your device stores it — in your browser's localStorage on the web, and in the device secure storage (iOS Keychain · Android encrypted storage) in the apps. On iOS it stays in the Keychain even after you delete the app, so reinstalling on the same device continues the same records. Section 10 below covers where it is kept and how to clear it. The backup code shown under "back up my records" is this token. Retention: until you delete your account.

Account email

If you link a Google or Apple account, we store the email address and the unique identifier the provider gives us. Nothing is collected if you never link an account. Retention: until you delete your account — there is no "unlink only" feature, so deleting the account is the only way to remove the stored email.

Apple refresh token

If you signed in with Apple, we keep the refresh token Apple issued, encrypted, so that deleting your account can actually revoke the Apple sign-in. Retention: discarded on deletion; if the revocation call fails we keep it for up to 7 days of retries and then discard it.

Attempt history

The words you submitted, whether they were correct, how many attempts you used, submission times, and your streak and solved counts. Whether you used the hint preview, and when, and the puzzle language you chose (Korean or English) are stored on the server alongside them. Used to build the leaderboard and statistics. Retention: until you delete your account.

Today's ranking

Your entry on today's leaderboard (both puzzle languages). Each row holds your guest number and that day's attempt count and solve time, and the displayed name is an anonymous label derived from that number; your name and email are never used. That number does link to your attempt history and linked account inside the service, so while those records exist we treat the ranking row as information that can be traced back to a person and protect it accordingly. Retention: deleting your account removes that day's entry immediately, and a past day's ranking is deleted automatically 8 days after the puzzle date. Nothing in the service shows past-day rankings; those 8 days are headroom for investigating outages and restores.

Subscription identifier

If you buy the ad-free subscription, we store the purchase identifier (transaction ID or purchase token) and expiry time that App Store or Google Play gives us. Payment methods and card details are handled by the store and never reach our server. Retention: until you delete your account (see the Terms of Service about cancelling).

Advertising ID

Apps only. The Google AdMob SDK bundled in the app uses your device advertising ID (IDFA on iOS, Advertising ID on Android) for ad requests. We do not store it on our server — the SDK sends it straight to AdMob. How to refuse or reset it is in section 10 below.

Access and error logs

To investigate failures, error stacks and processing records are written to our server logs, and the path and time of a failing request are sent to Sentry. To measure performance we also send Sentry the path and response time of a sample (about 10%) of normal requests. On top of that we keep access logs for the personal-data processing system in two layers: personal-data actions such as opening an operator page, deleting an account, reading your own records, or linking an account are recorded in the database as who, when, from where, what, and the outcome (an operator email is stored only masked, as h***@example.com), and every web request, those actions included, is recorded in an access log file (remote IP, time, method, path, status, response size, browser, response time). These logs never record tokens, backup codes, full email addresses, cookies, or query strings, and Sentry is configured not to receive request bodies, query strings, cookies, IP addresses, or user identifiers. Retention: access logs are kept for one year (365 days) and then deleted automatically (Art. 8(1) of the Standards for Securing the Safety of Personal Information), and we review them at least once a month. Sentry deletes events under its own retention policy.

We back up the database every hour to a backup server in Korea, where each backup is kept for 14 days (the production server also keeps the last 7 days), and once a day an encrypted copy of the latest backup is stored in Google Drive (7 daily, 4 weekly, and 3 monthly generations; even the oldest copy is deleted within 3 months — section 6). So when you delete your account the data disappears from the service immediately, but it may remain in backups taken earlier — for up to 14 days on the backup server in Korea and up to 3 months in the encrypted Google Drive copies — before those are discarded in turn.

4. Sharing with third parties

The companies below are third parties that also process the data under their own policies and for their own decisions. We integrate only within the scope their terms and policies allow.

Google (sign-in · Google Play subscription verification · AdMob ads)

Recipient: Google LLC. Shared: Google account identifier and email (if you link one), subscription purchase token, ad request data and the device advertising ID. Purpose: sign-in, subscription validity, serving and measuring ads. Retention: per Google's own policy; what we store is deleted when you delete your account.

Apple (sign-in · App Store subscription verification)

Recipient: Apple Inc. Shared: Apple account identifier and email (if you link one), subscription transaction ID. Purpose: sign-in, subscription validity, revoking the connection when you delete your account. Retention: per Apple's own policy; what we store is deleted when you delete your account.

We do not otherwise provide, sell, or share personal data with third parties for advertising or marketing. We disclose data where the law requires it, and only to that extent.

5. Processors we delegate work to

These processors handle data only for our purposes and only within the work listed.

Google (Firebase Analytics)

Delegated work: aggregating app usage events (puzzle completed, hint unlocked, rewarded ad completed, share, paywall view, subscription start, past puzzle opened, past puzzle completed, past puzzle lock tapped).

Sentry

Delegated work: error tracking. Collecting and storing request context and stack traces.

Google (Google Drive)

Delegated work: storing database backup copies for disaster recovery. Each copy is encrypted before upload and Google is never given the decryption key, so Google only stores the copies and cannot read them (section 6).

The production server, its database, and the backup server are all machines the operator runs directly in Korea, so no hosting is delegated. If the work or the processors change we update this section and the effective date. When the service no longer needs the data, we also ask these processors to delete it.

6. International transfer

The companies above run servers outside the Republic of Korea, so using those features transfers data abroad. Database backup copies for disaster recovery are also stored abroad (Google Drive). Instead of asking for separate consent we rely on PIPA Art. 28-8(1)3 — a transfer necessary to perform our contract with you, including delegated processing and storage — and publish the disclosures required by Art. 28-8(2) below.

Google (sign-in · Google Play subscription verification)

• Items transferred: Google account identifier and email, subscription purchase token
• Country, time, method: the United States and other countries where Google runs servers / when you use the feature / HTTPS network transfer
• Recipient and contact: Google LLC (published channel: policies.google.com/privacy)
• Purpose and retention: sign-in and subscription validity / per Google's retention policy
• How to refuse, and the effect: Sign-in — if you never link a Google account, there is no transfer; you can still solve the puzzle, and only continuing the same records across devices stops working. There is no way to unlink a linked account, so if you no longer want the transfer, delete your account (see “Your rights” below). Subscription verification is separate from linking: even without a linked account, buying the ad-free subscription on Google Play sends that purchase token to Google for verification. To refuse that transfer, do not buy the subscription; refusing only means you cannot remove the ads.

Apple (sign-in · App Store subscription verification)

• Items transferred: Apple account identifier and email, subscription transaction ID, Apple refresh token
• Country, time, method: the United States and other countries where Apple runs servers / at sign-in, subscription verification, and revocation / HTTPS network transfer
• Recipient and contact: Apple Inc. (published channel: apple.com/legal/privacy)
• Purpose and retention: sign-in, subscription validity, revoking the connection / per Apple's retention policy
• How to refuse, and the effect: Sign-in — if you never link an Apple account, there is no transfer, and the effect is the same as for Google above. Revocation is not a way to stop a transfer; it is one: when you delete an account you linked, we send the Apple refresh token we stored to Apple in order to revoke the connection. If that transfer fails we keep that token alone after the account records are gone, send it again every day for up to 7 days, and then discard it. Once you have linked an account you cannot refuse this transfer, so to refuse it, never link an Apple account. Subscription verification is separate from linking: even without a linked account, buying the ad-free subscription on the App Store sends that transaction ID to Apple for verification. To refuse that transfer, do not buy the subscription.

Google AdMob (ads in the apps)

• Items transferred: device advertising ID (IDFA/ADID) and ad request data (coarse location, device type, and the other values the SDK collects)
• Country, time, method: the United States and other countries where Google runs servers / whenever the app requests an ad / sent by the SDK over HTTPS without passing through our server
• Recipient and contact: Google LLC (published channel: policies.google.com/technologies/ads)
• Purpose and retention: serving and measuring ads, click-fraud prevention / per Google's retention policy
• How to refuse, and the effect: you can refuse personalized-ads consent through the iOS tracking permission request and the app's "Ad privacy settings" (shown where it applies). Refusing turns off personalized ads, but the ad request itself still goes to AdMob. To stop ad transfers entirely, use the ad-free subscription or delete the app.

Google Firebase Analytics (app usage events)

• Items transferred: app instance identifier; the names and parameters of the events we log ourselves (puzzle completed, hint unlocked, rewarded ad completed, share, paywall view, subscription start, past puzzle opened, past puzzle completed, past puzzle lock tapped — the parameters are only the puzzle language (ko/en), whether you solved it, how many tries you used, whether an ad was watched, how many days ago the past puzzle was, whether a shared result was a past puzzle, and which button opened the subscription screen; your guesses and contact details are never sent); and the default events the Firebase SDK collects automatically (first open, session start, screen view and the like) together with the device and app details attached to them (device model, OS version, app version, app language, and an approximate region estimated from your IP address). On Android we have turned off Firebase's advertising-ID collection; iOS has no such setting, so if you allowed tracking your advertising ID (IDFA) may be sent along
• Country, time, method: the United States and other countries where Google runs servers / when the event happens in the app / sent by the SDK over HTTPS
• Recipient and contact: Google LLC (published channel: firebase.google.com/support/privacy)
• Purpose and retention: counting feature usage to improve the service / per Google's retention policy
• How to refuse, and the effect: this happens in the apps only, and there is no per-feature opt-out today. To refuse the transfer you have to stop using the apps (the web app sends none of it).

Sentry (error reports)

• Items transferred: request path, timestamp, and stack trace at the moment of an error (emails and tokens masked), plus the path and response time of a sample (about 10%) of requests for performance measurement
• Country, time, method: the United States and other countries where Sentry runs servers / when an error happens, and when a request is picked for the sample / HTTPS network transfer
• Recipient and contact: Sentry (published channel: sentry.io/privacy)
• Purpose and retention: finding and fixing outages, and measuring response times / deleted automatically under Sentry's retention policy
• How to refuse, and the effect: this happens on both web and apps and we need it to fix outages, so there is no per-feature opt-out. To refuse the transfer you have to stop using the service.

Google Drive (encrypted database backup storage)

• Items transferred: an encrypted database backup (all member and game records) — the whole backup file of the items in section 3 that live in our server database (guest token, account email, attempt history, subscription identifier, access logs, and so on), encrypted as a single copy
• Country, time, method: the United States and other countries where Google runs servers / once every day, when the backup server in Korea uploads that day's latest backup / encrypted with a public key (age) before upload, then sent over HTTPS
• Recipient and contact: Google LLC — Google Drive storage (published channel: policies.google.com/privacy)
• Purpose and retention: disaster-recovery backup storage (restoring the service if the machines in Korea are damaged together) / rotated as 7 daily, 4 weekly, and 3 monthly generations, and even the oldest copy is deleted within 3 months. Google is never given the decryption key and cannot read the copies
• How to refuse, and the effect: backups cover the whole database, so there is no per-user opt-out. To refuse the transfer, stop using the service and delete your account (section 8) — copies made after deletion no longer contain your records (except that, for an account linked with Apple, if the revocation transfer fails the encrypted Apple refresh token alone stays for up to 7 days and is included in copies made in that time — section 7), and copies already uploaded are all deleted within 3 months as the generations rotate.

The apps still send ads, usage events, and error reports even without a linked account, and buying a subscription sends the purchase identifier to the store as well, and the records kept on our server are stored in Google Drive as encrypted backup copies — using the service without an account is not a way to refuse international transfer. If you cannot accept these transfers, please stop using the service and delete your account and records as described in section 8.

7. How we destroy data

We destroy personal data without delay once its retention period ends or its purpose is fulfilled.

• Procedure: when a deletion request arrives (web /account/delete, "Delete account" in the app, or an email request) a single transaction deletes your attempt history, streak, linked account, subscription identifier, hint records, and guest token, and removes today's leaderboard entry. There is no "kept after deletion" period. Deleting from the app also replaces the guest token in the device secure storage with a newly issued one at the same moment, so that device cannot get back into the deleted records (section 10).
• Method: database rows are deleted immediately and cannot be recovered from the service; the encrypted Apple refresh token is destroyed as soon as revocation finishes, or after at most 7 days if revocation keeps failing. Backups are deleted as whole compressed dump files — after 14 days on the backup server in Korea (7 days for the copy on the production server), and in Google Drive as the generations rotate, within 3 months at the latest. Dumps in Korea are readable only by the operator account, and the copies sent to Google Drive are encrypted with a public key (age) before upload; the decryption key is kept neither on our servers nor in Google Drive, so opening the Drive storage does not reveal the contents of a copy. We hold no printed personal data.
• Access and error logs: Sentry deletes them under its own retention policy, and access logs for the personal-data processing system are deleted automatically once their one-year retention period has passed (access log files are rotated and compressed daily and then deleted on the same schedule).

8. Your rights and how to exercise them

You can ask to access, correct, delete, or suspend the processing of your personal data at any time (PIPA Art. 35-37). The legal representative of a child under 14 may exercise the same rights on the child's behalf.

• Deletion: web chosung.dosaem.com/account/delete, or "Delete account" at the bottom of the My Records screen in the app. This cannot be undone. Deleting the app is not deletion — on iOS the guest token stays in the device secure storage even after the app is gone (section 10).
• Access, correction, suspension: write to the email in section 12 below and we will tell you the outcome, or how long it will take, within 10 days of receiving the access request.
• Representative: with a letter of authority, an agent may act for you.

Deleting removes your guest token, attempt history, linked account, subscription identifier, and today's leaderboard entry. It does not cancel your subscription — you must cancel in App Store or Google Play to stop being charged. Where the law requires us to keep records, we may limit a request to that extent and will tell you why.

9. How we protect it

We take the measures below under PIPA Art. 29 and Enforcement Decree Art. 30.

• Encryption in transit: every web and app request travels over HTTPS only.
• Encryption at rest: sensitive values such as the Apple refresh token are stored encrypted.
• Access control: operator pages are limited to an allow-list of operator accounts, and state-changing requests are protected with a CSRF token.
• Log minimisation: our server logs and error reports do not record identifying values such as full email addresses or tokens (operator emails appear masked only).
• Access log retention and review: access logs for the personal-data processing system are kept for one year and then deleted automatically, and we review them at least monthly. Each record carries a hash chain so tampering is detectable (Art. 8 of the Standards for Securing the Safety of Personal Information).
• Backups: taken every hour and kept for 14 days on a backup server in Korea; once a day the latest backup that passes a restore check is encrypted with a public key (age) and stored in Google Drive, with quarterly restore rehearsals. The decryption key is kept apart from the servers and Google Drive.

10. Automatic collection — cookies, device storage, advertising IDs, analytics SDKs

Cookies

On the web we use a signed session cookie to keep you signed in and to hold the deletion confirmation form together. We use no advertising or analytics cookies. You can refuse or clear cookies in your browser settings; if you refuse them, linking an account and the web deletion page stop working. The guest token on the web is not a cookie — it lives in your browser's localStorage and clearing site data removes it (that device then cannot continue its records). Where the apps keep it is the "Device secure storage" entry below.

Device secure storage (the guest token in the apps)

The apps keep the guest token, and device markers such as "you have already seen this notice", in the device secure storage (iOS Keychain · Android encrypted storage). This exists so your records continue without signing in, and the only one of these values sent to the server is the guest token that authenticates your requests. The iOS Keychain survives deleting the app — reinstalling on the same device brings back the same guest token and your records continue (on Android it is removed together with the app). To clear your records so they do not come back, use "Delete account" (at the bottom of the My Records screen in the app) or the web page chosung.dosaem.com/account/delete before you delete the app: that deletes your records on the server, and deleting from the app also replaces the guest token in the device secure storage with a newly issued one on the spot, so there is no way back into the deleted records. Deleting the app alone removes neither your records on the server nor the token in the iOS Keychain.

Ordinary app storage (device settings in the apps)

Device settings (whether you have already seen the onboarding, whether notifications are on and at what time, which dates to skip a reminder for, and which interstitial ads you have already seen) live in ordinary app storage (Android SharedPreferences · iOS NSUserDefaults) rather than the secure storage above. These values stay on the device and are never sent to our server. On Android they are removed together with the app, and we also exclude them from Google Drive backup and from device-to-device transfer, so reinstalling starts from the onboarding again. On iOS they are removed with the app too, but the guest token stays in the Keychain as described in the entry above.

Advertising ID (IDFA / Advertising ID)

The AdMob SDK in the apps uses your device advertising identifier for ad requests. On iOS, turn off an app's tracking request under Settings > Privacy & Security > Tracking; on Android you can reset the advertising ID or delete it under Settings > Privacy > Ads. You can also revisit personalized-ads consent under "Ad privacy settings" in the app where that applies. To remove ads altogether, use the ad-free subscription or delete the app.

Analytics SDK (Firebase Analytics)

Apps only; it counts screen and feature usage events. Besides the nine events we log ourselves (section 6) there are the default events the Firebase SDK collects automatically (first open, session start, screen view and the like), and every transfer carries an app instance identifier: a different value from the advertising ID, regenerated if you delete and reinstall the app. On Android we have turned off Firebase's advertising-ID collection (AdMob's own use of it for ad requests is unchanged, as described under "Advertising ID" above); iOS has no such setting, so if you allowed tracking your advertising ID may be sent along. There is no per-feature opt-out — deleting the app stops the transfer. The web app has no analytics SDK.

11. Children under 14

The service is not for children under 14 and we do not knowingly collect data from them (PIPA Art. 22-2). If we learn that records belong to a child under 14 we delete them without delay. Tell us at the contact address and we will delete those records without asking for proof of legal representation.

12. Privacy officer and access-request channel

Privacy officer

Operator (job title) · [email protected]
This is a one-person business, so the owner is also the privacy officer. PIPA Art. 31 asks for a name or a job title plus contact details; we currently publish the job title and the email address.

Access-request channel

The same address receives and handles every access request, correction, deletion, and suspension request. With one person operating the service, intake and handling share one channel.

13. How to seek redress

If you need advice or dispute mediation about a privacy violation, you can contact the Korean public bodies below. They are independent of this service.

• Personal Information Infringement Report Centre: 118 (privacy.kisa.or.kr)
• Personal Information Dispute Mediation Committee: 1833-6972 (kopico.go.kr)
• Personal Information Protection Commission: pipc.go.kr

If a request under PIPA Art. 35, 36, or 37 is refused and your rights are infringed, you may also file an administrative appeal under the Administrative Appeals Act.

14. Notice for users outside Korea

The service is operated from the Republic of Korea and follows Korean privacy law. For users in the European Union, the United Kingdom, and California, here is the minimum you should know.

• EU and UK (GDPR / UK GDPR): our legal basis is performance of the contract to provide the service (Art. 6(1)(b)) and legitimate interests in incident response and ad delivery (Art. 6(1)(f)). You can exercise the rights of access, rectification, erasure, restriction, portability, and objection (Art. 15-21) at the email in section 12, and you have the right to lodge a complaint with your supervisory authority (Art. 77). Data is processed in Korea and in the countries listed in section 6.
• California (CCPA/CPRA): we do not sell or share personal information (including "sharing" for cross-context behavioural advertising — nothing is provided for valuable consideration). Exercise your rights to know, delete, and correct through sections 8 and 12, and we will not discriminate against you for doing so.

15. Changes to this policy

When the content changes we update the effective date on this page and post what changed here from seven days before it takes effect. Changes that materially affect your rights are announced in the app and on the web. If you need an earlier version, ask at the email in section 12 and we will send it.

What changed

• Effective 2026-11-04 (posted 2026-10-28): for the app's past-puzzle feature, the events we log ourselves gained three aggregate events of the same kind (past puzzle opened, past puzzle completed, past puzzle lock tapped) and three parameters (how many days ago the past puzzle was, whether a shared result was a past puzzle as 1/0, and which button opened the subscription screen). We updated the event descriptions in sections 5, 6, and 10. There is no new kind of personal data — what we collect, our processors, and the recipients of international transfers are unchanged.
• Effective 2026-10-29 (posted 2026-10-22): the backup structure changed — we back up every hour to a backup server in Korea and keep each backup for 14 days, and once a day an encrypted copy is stored in Google Drive (Google LLC, United States) for up to 3 months. We added this storage to section 6 (international transfer) and section 5 (processors) and updated the backup descriptions in sections 3, 7, and 9. The production server is moving to another machine the operator owns in Korea; after the move, the production server and the backup server are still run directly by the operator in Korea.