Iko Travel Privacy Policy v2 (Accounts Edition · English)

This is a draft, and it is not yet in force. Iko Travel has not launched, and the account feature is not available. We are publishing this policy while preparing for launch so that there is an address where you can actually read it. It has not yet been reviewed by a lawyer.

It is written from what the app's code actually does, and it is not legal advice.

Where a value is still undecided we have left it visible in the text as an unfinalised marker rather than filling in a guess. The remaining items are collected in §16.

When the service opens, we will enter the effective date below, and the policy applies from that day.

• Draft written: July 30, 2026
• Effective date: [Not yet decided: effective date — set on the day the service opens]
• Last updated: August 2, 2026
• Public URL: https://travel-iko.pages.dev/en/legal/privacy-policy
• Relationship to the previous version: the draft dated July 22, 2026 (v1) is kept, not withdrawn. This v2 reflects the account feature introduced after v1, and applies from its effective date.

1. Scope

[Not yet decided: legal business name] ("we", "us") operates the travel app Iko Travel (the "Service") and complies with the Personal Information Protection Act of the Republic of Korea (PIPA) and other applicable laws. We treat your personal information with care, and our design principle is to prefer a structure that does not collect personal information in the first place.

• What this covers: the iOS and Android app and the server (API) behind it
• Languages: English, Korean, and Japanese. If the language versions differ in meaning, the Korean version governs. [Not yet decided: legal review of the governing-language clause]
• Business details: name [Not yet decided: business name] / representative [Not yet decided: representative] / business registration number [Not yet decided: business registration number] / address [Not yet decided: address]

1.1 How the Service is built

You need to know four structural facts to read this policy.

1. The Service has an account feature built on social sign-in, but we do not offer it to you today. It starts working only once the server configuration explicitly turns it on and the app ships with a sign-in method; until then no sign-in entry point appears on screen at all. (§11)
2. No screen asks you for your name, email address, or phone number. That stays true when the account feature is offered, and we do not receive those items from sign-in providers either. (§2.3, §11.2)
3. The values that identify you fall into three separate strands that are not linked to one another — the install identifier (§2.2), the account identifier (§2.3), and the payment identifier (§2.2). None of them can be derived from another.
4. The server structurally blocks anything sent to the AI features so that only predefined items can pass. (§2.1)

2. What we collect

2.1 What we never collect (blocked in code)

We do not collect the following to our server, and the block is written in code rather than left to policy.

• the raw text of your question (raw_query)
• location coordinates (gps, latitude, longitude)
• your itinerary and your favorites
• your name, email address, and phone number

The server walks the whole body of every request to the AI features recursively and rejects the request (HTTP 400) the moment it finds any of those field names anywhere inside it. The error log that results keeps only the name of the blocked field — never its value, under any circumstances.

ℹ️ That block covers the AI features. Two other features — route search and weather — do send coordinates to our server as request values: the coordinates of the places you picked. Those are not the position your device measured (§9), and the server uses them only as a cache key rounded to a coarse grid, never stored alongside an identifier for you. §5 sets out how far those coordinates travel beyond us.

2.2 Device identifiers

ℹ️ The install identifier holds no real identity information, but it does let requests from the same device be linked to each other. We therefore treat it as a per-device anonymous identifier rather than as "fully non-identifying data", and we disclose it here.

2.3 Account identifiers

If the account feature is offered (§11), the following values are stored on our server.

ℹ️ Devices and accounts behave differently. Deleting the app clears the device-side values in §2.2, but it does not clear your account. Reinstall the app, sign in the same way as before, and you are back in the same account. To get rid of the account itself, use account deletion (§11.6).

2.4 What leaves the Service when you use the AI features

To generate an AI answer we send the following to Anthropic (United States), limited per feature. Anything not listed below cannot be sent, because of the block described in §2.1.

• On the concierge and narration paths, places are referenced only by identifier; we do not send the place descriptions themselves.
• "Scrubbed question text" means the sentence you typed after the app has processed it on your device. The raw text of your question goes neither to our server nor outside it. [Not yet decided: compare the scrubbing implementation against the spec (what is masked, what can survive) and reflect the real scope here]
• Signing in changes nothing in the list above. We do not send your account identifier or your provider user reference to the AI service.

2.5 Subscription and payment items

Subscriptions are purchased through the app stores and a payment relay service (RevenueCat). The only values our server keeps are these.

• Subscription tier, expiry time (expiresAt), and plan tier
• Group entitlement details — the group identifier and the tier and expiry granted through that group, if you use the group feature
• The underlying personal entitlement record those values were derived from

We neither collect nor keep your name, email address, card number, or any other payment credential. The only thing we pass to the payment relay is the payment_id from §2.2, and the mapping between payment_id and our internal processing exists only inside our own server (kept for 400 days, §4). If the account feature is offered, these values are keyed to your account identifier instead of your install identifier.

2.6 Items collected when personalization (taste) is on

→ Described separately in §8. This feature is off by default today.

2.7 Items generated while we run the Service

• Request logs (errors, blocked requests, and the like): recorded at the level of field names, never values, exactly as in §2.1.
• Usage counters: numbers such as API call counts, needed to enforce usage limits. We count them per install identifier when you are signed out, and per account identifier when you are signed in.
• Account operation records: we record the fact that an account deletion or merge happened, at the level of the account identifier. Provider user references, revocation tokens, raw install identifiers, and raw payment identifiers never appear in these records in any form.

3. Why we process it

We process what we collect only for the purposes below. If a purpose changes, we tell you first and obtain any consent required.

4. How long we keep it, and how we destroy it

Retention differs by item. Some items expire automatically in the store that holds them; others have no automatic expiry set today. The table states this exactly as it is.

• Note A — When you delete your account, the account record and the sign-in link records are not erased; they stay in a "deleted" state. This is what stops an earlier account from coming back to life if you sign up again with the same sign-in method. The minimal record holds the account identifier, the provider user reference, the status, and timestamps. We have not yet decided how to destroy it fully (§16 B-9).
• Note B — Deleting your account clears only the usage counters for the current month, the previous month, today, and yesterday. Counters from earlier periods can remain (§16 B-10).
• Note C — Items stored on your device (install identifier, payment identifier, session token, favorites, consent records) are excluded from backup and device-to-device transfer, so they do not follow you to a new phone (§13-7).
• We delete information held in electronic files in a way that cannot be reversed.
• If the law requires us to keep something, we keep it for the period the law sets. Today there is nothing we hold back for a statutory retention duty.
• On statutory retention of payment records (checked on August 2, 2026 against the Korean Law Information Center, text in force from July 21, 2026) — Article 6 of the Korean Act on Consumer Protection in Electronic Commerce, together with Article 6(1) of its Enforcement Decree, requires a business to keep records of labelling and advertising for 6 months, records of contracts and withdrawals of offer for 5 years, records of payment and of the supply of goods for 5 years, and records of consumer complaints and dispute handling for 3 years. However, the personal information that Article 6(2) allows to be kept alongside those records is limited to information that identifies a party to the transaction, such as name, address, or e-mail address — and we hold none of those (§2). Subscriptions are also transacted through the App Store and Google Play, so we are not the party to the payment. Whether this duty reaches us therefore has to be settled by legal review. [Not yet decided: have counsel decide whether we count as the business (mail-order seller) under that Act for store-mediated subscriptions — if we do, add the statutory retention rows and periods to the table in §4]

5. Third parties and processors

We do not sell your personal information, and we do not hand it to third parties for advertising or marketing. We use the outside services below only as far as running the Service requires.

The table mixes two kinds of thing: services our server calls on your behalf, and services the app connects to directly, without passing through our server. The second kind is marked "app connects directly".

• TourAPI (Korea Tourism Organization): our server gathers the festival and event text on its own, and your personal information plays no part in that. The photos, however, are fetched by the app straight from the Korea Tourism Organization's server (see the table above).
• Anything marked "app connects directly" bypasses our server. We therefore cannot inspect or restrict what passes at that moment, and the relevant company's own privacy policy applies alongside ours (§16 B-17).
• How we build the place and map data inside the Service: we take public sources — OpenStreetMap, Wikidata and Wikimedia Commons, Korea's public data portal, and others — and download and process them ahead of time, during development. None of that happens while you use the Service, and your personal information plays no part in it.
• We do not ask sign-in providers for your name, email address, or phone number, and we do not receive them. The only thing we learn about you is the user reference that provider issued.
• [Not yet decided: confirm which data processing agreements (DPAs) and standard contractual clauses (SCCs) are in place with each company above, then have counsel decide whether each is a transfer to a third party or an entrustment to a processor, and finalise this table's title and columns — including how the 5 sign-in providers are classified (§16 C-9)]

6. Transfers of personal information to other countries

We transfer personal information out of Korea as follows.

• About RevenueCat (checked on August 2, 2026) — the recipient's registered name is RevenueCat, Inc., and that company's own privacy policy (updated June 2026) states that *"customer data sent to RevenueCat from around the world is sent to AWS data centers located in the United States."* That is why we list the country as the United States. The same policy gives a retention period of *"as long as you have an account with us ... and for six years after that"*, but that document alone does not tell us whether the same wording covers the subscription data of this app's users. [Not yet decided: settle the retention period for user subscription data through our contract (data processing agreement) with RevenueCat]
• We disclose these transfers through this policy and secure the measures needed for recipients to protect personal information. [Not yet decided: describe the recipients' level of protection concretely (certifications, contractual safeguards) — required by Apple 5.1.2(i)(d)]
• Recipients located in Korea are not in this table. SK Telecom (TMAP), the Korea Meteorological Administration, the Seoul Metropolitan Government, NAVER (local search and the Maps SDK), and the Korea Tourism Organization are all inside Korea, so no cross-border transfer arises. §5 sets out what passes between us and each of them.
• Affiliate booking links (§5) are not in this table either, because you move to the outside site yourself and it needs to be decided whether that counts as a transfer by us (§16 C-16).
• The 5 sign-in providers are involved only when you actually sign in that way. Nothing passes between us and a provider you never used.
• Under the Act on the Protection of Personal Information of Japan (APPI), telling users the recipient's country is not enough on its own; we must also describe that country's personal information protection regime. The countries are listed above, and the regime summaries are given in the Japanese version of this policy. [Not yet decided: write the country-regime paragraph in the Japanese version]

7. Using the AI features

This section covers what services built on generative AI are expected to disclose.

7.1 Your input and the AI's output

• Your input: only the scrubbed question text described in §2.4 reaches the AI. The raw text of your question does not, and your name, email address, phone number, location coordinates, itinerary, and favorites cannot, because of the block in §2.1.
• The course narration feature has no free-form input field at all, so nothing you write reaches it.
• The AI's output: the answer text is shown to you, and we do not separately accumulate it against your identifier. [Not yet decided: confirm whether AI answers are stored or cached server-side, then finalise this sentence]

7.2 Whether your input trains AI models, and how to opt out

• We do not provide your input to train AI models. [Not yet decided: obtain the contractual document confirming that Anthropic's commercial API does not train on customer data]
• We do not use your input to train our own models either.
• How to opt out: if you do not use the AI features, nothing you type is ever sent. If you want processing stopped or data deleted for something already sent, ask through the contact point in §14.

7.3 Reporting a bad answer

If the AI gives you an answer that is wrong or inappropriate, you can report it as follows.

• In-app reporting path: [Not yet decided: decide the in-app reporting path (build it if it does not exist)]
• Email: [Not yet decided: email address for reports]

We review what you send and use it to improve prompts and blocking rules.

7.4 The limits of AI answers

AI answers are a starting point, not a guarantee. Hours, prices, and closing days change locally. Please confirm anything important with the original source.

8. Personalization (taste)

8.1 Where this stands today

This feature is off by default. It works only when the server configuration explicitly turns it on; if the setting is missing or unreadable, it does not turn on and simply stays off. What follows tells you in advance what applies once it is on.

8.2 What we collect

• Only taste tags drawn from a predefined list (enum), their weights, and the time they were updated.
• We do not store free-form text, names, contact details, or location coordinates.

8.3 Consent

• The feature works only for requests that carry the dedicated consent signal (X-AI-Personalization-Consent). Declining costs you nothing else; the rest of the Service works as before.
• [Not yet decided: confirm the in-app consent UI (screen, wording, withdrawal path) and capture screenshots — for Apple 5.1.2(i)(c)]

8.4 Where it is stored, how long it lasts, and how to delete it

• Stored in Cloudflare Workers KV. The storage key is built from your per-device anonymous identifier while you are signed out, and from your account identifier once you sign in.
• When you sign in, existing taste data moves to the account side and the device-side copy is deleted — it moves, it is not copied. When two accounts are merged, the data is combined into one side and the other side is deleted.
• Retention: it expires automatically after 180 days.
• Deletion: you can ask us to delete it at any time, and the Service always exposes a deletion endpoint for it (DELETE /v1/ai/taste). Deleting your account deletes your taste data too (§11.6). [Not yet decided: decide where the in-app "delete my taste data" button lives]

9. Location

• The app really does use your device's location to show "my location" on the map screen. For that it asks for while-in-use location permission on iOS, and precise or approximate location permission on Android.
• We do not send the coordinates to our server. The server structurally blocks latitude, longitude, and GPS fields (§2.1), and inside the app the location value is used only to draw the map screen.
• As far as we could verify, nothing in the app stores the location value persistently on the device either.
• The map screen itself, however, is drawn by Google's and NAVER's Maps SDKs. While you look at the map, where it is looking and how far it is zoomed go straight to those companies, and if you turn on the "my location" display, your device's position goes to them through the SDK as well. That traffic does not pass through our server (§5, §6).
• The coordinates used for route search and weather are the coordinates of the places you picked, not the position your device measured. §5 sets out how far they travel.
• You can withdraw location permission at any time in your device settings. Doing so disables only the "my location" display; everything else keeps working.

ℹ️ We deliberately avoid the claim that no location is ever collected. The accurate statement is "we use it on your device and never send it to our server".

[Not yet decided: legal review of whether the Korean Act on the Protection and Use of Location Information requires registration as a location information or location-based service provider]

10. Advertising and tracking

• The Service includes the Google AdMob ad SDK.
• While the ad feature is off, the ad consent flow and the tracking prompt are never invoked.
• While it is on, consent runs in this order.
  1. The Google User Messaging Platform (UMP) consent form — you choose whether your data may be used for advertising.
  2. (iOS only) The App Tracking Transparency (ATT) prompt — you choose whether to allow tracking across other companies' apps and websites.
• Where this stands today (stated honestly): the app is wired with the real ad unit identifiers issued to us, and release builds shipped to the stores use them. Only development and test builds use Google's sample (test) values. Release builds can therefore serve real ads. [Not yet decided: confirm when commercial ad serving starts and keep this section and the store declarations in sync with it]

11. The account feature

11.1 Where this stands today

We do not offer the account feature today. It applies from the moment the server configuration explicitly turns it on and the app ships with a sign-in method. Until then no sign-in entry point appears in the app, and the account endpoints on the server do not respond. What follows tells you in advance what applies once it is offered.

11.2 Sign-in methods, and what we receive

• Accounts are created only through social sign-in. There is no step where you create an ID and password.
• By design the Service supports 5 sign-in providers — Apple, Google, Kakao, Naver, and LINE. What you can actually use is exactly what the app shows on screen.
• The only thing we receive from a sign-in provider is your user reference. We do not request, receive, or keep your name, email address, profile picture, or phone number.
• Only when you sign in with Apple do we also keep one revocation token (§2.3, §11.7).

11.3 Your sign-in session

• When you sign in successfully, our server issues a session token and the app keeps it on your device to keep you signed in.
• The session token is valid for 30 days. When the app checks the session with the server and less than half that period is left, the server issues a fresh token.
• We store your session information in the app's internal database without encrypting it separately.
  We do not use the secure storage the operating system offers (the iOS keychain and similar) because that storage keeps values even after the app is deleted, which would create a state where deleting the app does not delete your identity. We chose to keep a structure where deleting the app also clears the identifying data inside your device.
  Instead, we put two measures in place.
  (1) A session is discarded automatically on the device 30 days after it was last checked.
  (2) When you run "Sign out of all devices" in settings, every session issued up to that point is invalidated on the server immediately.
  We state the limit plainly. Those measures do not protect a device whose own protections have been removed (a rooted or jailbroken device). On such a device the stored session information can be exposed, and an exposed session is enough to delete the account. If you lose your device or hand it to someone else, run "Sign out of all devices".

11.4 Linking and unlinking sign-in methods

• You can link several sign-in methods to one account. The app lists what is linked, showing only the provider name and when it was linked.
• You can also unlink one. But you cannot unlink the last remaining sign-in method — doing so would leave no way back into that account.
• If you try to link a sign-in method that already belongs to another account, we do not link it. Instead we tell you whether the two accounts can be merged (§11.5).

11.5 Merging accounts

• You can merge two accounts into one. A merge cannot be undone.
• Merging moves one account's sign-in methods, subscription status, group membership, and taste data to the other. The account that was moved out of enters a "merged" state and can no longer be used on its own.
• If both accounts have a payment attached, merging does not combine the subscriptions. You have to cancel whichever one you no longer need in the store.
• Before you run a merge, we show you a screen explaining what will change.

11.6 Deleting your account

You can delete your account in the app (Settings → Account → Delete account). If you cannot install the app, ask through the contact point in §14.

What gets deleted

• The sign-in methods linked to the account (after this, they no longer sign you in to it)
• Your subscription status and paid entitlements
• Your taste tags, if you used personalization
• Usage records for the recent periods
• The link between your payment identifier and your account
• Your single seat in a group

What stays after deletion, and why

We will not tell you that "everything is erased". Here is what actually stays.

1. A minimal account record — your account identifier and provider user reference stay, marked "deleted". They stop an earlier account from being revived when you sign up again with the same sign-in method. We have not yet decided how to remove this record entirely (§16 B-9).
2. Part of your usage records from earlier periods — we clear the recent periods, but records from before them can remain (§16 B-10).
3. The install identifier on your device — a value we leave on the device so paid entitlements do not pass to the wrong account. Deleting your account does not clear it, and if you sign up again on the same device, some payment links can be limited.
4. Management information for groups you own — if you own a group, its owner field keeps a value pointing at the deleted account. Removing it would leave the remaining members unable to manage the group.
5. Payment records held by the stores and the payment relay — we cannot erase what the App Store, Google Play, and the payment relay keep. Their own policies govern them.
6. Operational and error logs — records we need to respond to incidents. We have not set a retention period yet (§4).

When it happens, and why it is final

• We process deletion at the moment you ask for it. There is no waiting period and no suspended in-between state.
• Deletion cannot be undone. We cannot bring back a deleted account or its data.
• If you have merged accounts before, deleting the account you use now also deletes the earlier account that was merged into it.
• For a very short window right after deletion, another process running at the same moment can briefly recreate a few values. A scheduled check finds them and clears them.

Cancel your subscription separately

Deleting your account does not cancel a subscription you started in the App Store or Google Play. Unless you cancel it, billing continues from the next renewal date. Cancel it yourself in the store where you bought it. We recommend cancelling before you delete your account.

11.7 Unlinking your sign-in providers

• When you delete your account, we also ask Sign in with Apple and Kakao to revoke the link. We can send that request only when the settings and information it needs are in place on our server.
• We cannot revoke the link for Google, LINE, or Naver. You have to remove those yourself in each service's own account settings.
• If we could not send a request to some provider, the app tells you at the end of deletion which ones you need to remove yourself.
• Where this stands today (stated honestly): the configuration values automatic revocation needs are not yet loaded on our server. In that state no request goes out to Apple or Kakao either, so every provider becomes one you remove yourself (§16 D-10).
• Leaving a link in place does not keep your account alive — it is already deleted on our side, and only the entry in the provider's list remains.

12. Your rights, and how to exercise them

You have the right to ask us to give you access to your personal information and to correct it, delete it, or stop processing it. Here is how that works in practice.

⚠️ Deleting the app is not the same as deleting your account. Deleting the app clears the data and the install identifier on your device, but your account on our server stays. To get rid of it, use account deletion (§11.6).

12.1 What to do for each item

• Items stored on your device are excluded from backup and device-to-device transfer, so data from your old phone does not follow you to a new one (§13-7).

12.2 Children under 14

[Not yet decided: decide whether children under 14 may use the Service and how legal guardian consent is handled — must match the age rating declared to the stores]

12.3 Where to raise a complaint

If you need advice or dispute mediation about how personal information is handled, you can contact bodies such as the Personal Information Dispute Mediation Committee, the Korea Internet & Security Agency's Privacy Infringement Report Centre, the Supreme Prosecutors' Office Cyber Investigation Division, and the National Police Agency Cyber Investigation Bureau. [Not yet decided: confirm each body's contact details and URL on its official site at publication time]

13. Security measures

We take the following measures.

1. Collect as little as possible: we handle only what running the Service requires, and we never built a screen that asks for identity information. We ask sign-in providers for nothing beyond the user reference.
2. Structural blocking of what is sent: requests to the AI features are validated against a predefined schema, and a request containing a forbidden field is rejected outright after a recursive check.
3. Minimal logging: blocked-request and error records keep field names, not values. Account records never keep provider user references, revocation tokens, raw install identifiers, or raw payment identifiers.
4. Separated identifiers: the payment identifier and the install identifier are generated so that neither can be derived from the other, and the server creates the account identifier independently of both.
5. Encrypted transport: traffic between the app and our server, and between our server and outside services, uses encrypted connections (HTTPS).
6. Restricted access: access to systems that handle personal information is limited to as few people as possible. [Not yet decided: audit our implementation against each item of the security-measures standard (access rights management, access log retention, and the rest) and make this concrete]
7. Data on your device is excluded from backup and device-to-device transfer.
   What the app stores on your device (favorites, consent records, your sign-in session, the install identifier, the payment identifier) sits in a single database file, and we set it to be excluded from both iCloud backup on iOS and cloud backup and device-to-device transfer on Android.
   This stops your sign-in session and device identifiers from being copied onto a device you did not intend. As a result, your favorites and consent records do not follow you when you change phones or restore a backup. A new device starts as a fresh install. We do not hold this information on our server, so we cannot restore it for you.
8. How your sign-in session is stored, and the limit of that: stated plainly in §11.3. In short, the session is stored in the app's internal database without separate encryption; the two mitigations are automatic discard after 30 days and "Sign out of all devices"; and neither protects a device whose own protections have been removed (rooted or jailbroken).
9. Signed session tokens: our server signs the session tokens it issues, and rejects any token whose signature does not match or whose period has passed. "Sign out of all devices" and account deletion invalidate every token issued before them.

14. Privacy officer and contact

For questions, complaints, or redress about how we handle personal information, contact us here.

• Privacy officer: [Not yet decided: privacy officer name] / [Not yet decided: privacy officer title]
• Contact: [Not yet decided: contact email] / [Not yet decided: phone number (optional)]
• Department handling requests: [Not yet decided: department name]

We answer and act on what you send us without undue delay.

15. Changes to this policy

• If we add to, remove from, or change this policy, we tell you through an in-app notice or the public URL 7 days before the change takes effect. For changes that materially affect your rights, we tell you 30 days ahead. [Not yet decided: settle the notice-period policy and confirm the in-app notice mechanism is built]
• We keep the change history at the end of this document or on a separate page. [Not yet decided: decide how the change history is maintained]
• Version history
  • v1 (written July 22, 2026) — the version before the account feature. Kept, not withdrawn.
  • v2 (written July 30, 2026, effective [Not yet decided: v2 effective date]) — adds the account feature (§11) and §2.3, §13-7, and §13-8; expands §3 to §6 and §12; corrects §10. On the same day, the results of a full audit of everything the Service sends outside were written into §5, §6, §9, and §16.

16. Things we have not settled yet

We have not settled the items below. We are listing them rather than hiding them. They need legal review and owner decisions, and the app cannot be submitted to the stores until they are resolved.

16.1 Mandatory fields left blank

16.2 Mismatches between code and policy, and unbuilt work

16.3 For legal review

16.4 Consistency with store review

*This policy is a draft and is not yet in force. The app cannot be submitted to the stores until the items in §16 are resolved and a lawyer has reviewed it.*