Privacy Policy

⚠️ LEGAL-UNREVIEWED — This is a draft. Do not publish it yet

• No lawyer has reviewed this document. A legal review before launch is mandatory (constitution §3).
• We have not re-verified the current text of the laws referred to here. United States privacy law is made mostly by individual states, it changes several times a year, and we have not checked any of the statutes named below against their current text. ADR 011 expressly prohibits citing country-specific legal requirements without fresh research, and that research has not been done for this version.
• Curly braces { } mark values we do not know yet. This is not a finished document until every placeholder in the table below is filled in.
• Remove this notice only after legal review is complete.

⚠️ Must be fixed before publishing — Article 6 (retention and deletion)

🔺 2026-08-11 · Spec 025 resolved part of this. That is why this block was rewritten rather than removed. 🔺 2026-08-15 · Spec 027 made the remaining half (anonymisation of plan data) a fact. This block is still not removed — 2 rows are still promises.

~~There is currently no code anywhere in this repository that actually enforces the retention periods stated in Article 6.~~ ~~→ Of the 7 rows in the Article 6 table, 4 are now actually enforced by code and 3 are not.~~ ~~→ Of the 7 rows in the Article 6 table, 5 are now actually enforced by code and 2 are not.~~ → Of the 8 rows in the Article 6 table, 6 are now actually enforced by code and 2 are not. 🔺 2026-09-25 · Spec 009C — report records were introduced, so a row "Report and moderation records — 1 year from when handling was finished" was added, and the same spec put that kind into the deletion command, so the row entered as a fact from the start.

~~Count: of 8 rows, 6 fully true · 0 half · 2 still a promise.~~ 🔺 2026-09-27 · Spec 065 — Count: of 8 rows, 7 fully true · 0 half · 1 still a promise. The "operational logs — 1 year" row became "service usage records · connection IP information — 3 months" (ADR 045), and because the server writes those records to daily files and itself deletes files older than 90 days, it became a true row from the start. The one remaining promise is payment records — 5 years. There are still 8 rows. ~~⚠️ The denominator is still 7. Spec 027 added no new kind of deletion — splitting a row to count 8 would break the count Spec 025 was approved on.~~ 🔺 2026-09-25 · 009C — the denominator went from 7 to 8. No existing row was split; a new record with its own retention period (1 year from when handling was finished) came into being. That Spec 027 added no new kind of deletion is still true.

⚠️ This does not mean "the deletion work is done, so we may publish." Two rows are still promises, and they were left unbuilt only because there is currently nothing to delete. The moment a subject appears (hosting, paid services) those rows become false immediately. This is structurally the same failure we already had with the location and marketing consent items — consent collected for something that did not exist. ⚠️ And even the 6 enforced rows do not delete anything by themselves. The deletion command must be run with its explicit "actually delete" flag, or the server's scheduled run must be switched on; both default to deleting nothing. Anonymisation happens only inside that same command — if nobody runs it, nothing is anonymised either. ⚠️ Remove this block only when the remaining 2 rows have become facts. 🔺 2026-09-27 · Spec 065 — the one remaining promise is payment records. The "server hosting" row above (operational logs) became a fact once the server started deleting those records itself after 90 days. Keep this block until the payment records row is a fact.

This matters more in the United States than in Korea. Several state privacy laws treat a materially inaccurate privacy notice as a deceptive practice in its own right, enforceable by the state attorney general and, in California, by regulation. Five rows of the retention section are now facts; two are still promises. Sources: docs/개인정보-대장.md §4-1 · Spec 025 §7-1 · Spec 027 §7-1 · the remaining work is item C15 in SPEC-PLAN.md.

⚠️ This version is written for the United States only

This English version is prepared on the basis of United States law. Users in the United Kingdom or the European Union are subject to UK GDPR / GDPR, which require additional disclosures not covered here — a separate version is required.

The disclosures missing for UK/EU users include, at minimum: a lawful basis for each processing purpose, the identity of a representative in the UK/EU, international transfer safeguards, the right to data portability, the right to object, rights relating to automated decision-making, and the right to lodge a complaint with a supervisory authority. None of that is in this document.

ADR 011 named the target market only as "English-speaking countries" and never narrowed it further. Which countries that phrase covers is still an open question.

⚠️ There is no single United States privacy law

The United States has no general federal privacy statute. Obligations come from a patchwork of state laws — California (CCPA as amended by CPRA), Virginia, Colorado, Connecticut, Utah, Texas and a growing number of others — plus sector-specific federal laws such as COPPA for children. Which rights you actually have depends on the state you live in, and the list of states changes every year.

We have written Article 10 to give every user the same set of rights, rather than tracking each state separately. That is the simpler and more protective approach, but it has not been checked against any individual state's requirements, and some states impose procedural duties (such as a formal appeals process) that this draft does not yet describe in full.

Linked consent record: legal_terms.key = privacy_policy (required consent) Source of record: docs/개인정보-대장.md — the data listed in this policy corresponds one-to-one with the 129 items that data actually flows into today in that inventory. 🔺 2026-08-10 — spec 023 raised that count from 51 to 56. The five additions are the applicable country (jurisdiction), the basis on which it was determined, and when it was determined (Article 2-3), plus the applicable country now recorded alongside each consent record and each consent history entry. 🔺 2026-08-15 — spec 007 raised that count from 56 to 63. All seven additions belong to the plan participant roster — which plan · who is on it · their role in that plan · the state of their invitation · whether they confirmed attendance · when they were added to the roster · when they answered the invitation (Article 2-3 and the "Providing the plans feature" row of Article 4). Collecting something without writing it down is an omission, so this policy was updated in the same change that created the roster. 🔺 2026-08-15 — spec 008 raised that count from 63 to 67. All four additions belong to invite links — which plan the link is for · who created it · the value used to match the link's secret · when the link was created (Article 2-3 and the "Providing the plans feature" row of Article 4). ⚠️ This spec also widened, for the first time, who can see what. Someone who receives an invite link is not yet a participant, yet they can see the plan's title, place and time, the creator's display name, and how many people are on it. Article 5 was rewritten accordingly. That is the whole of it — the participant list itself is not shown. ✅ Three things invite links did not add: which link someone came in through · when and where a link was opened (access logs) · why a join was refused. None of them exist, so the Article 6 table still has 7 rows. 🔺 2026-08-16 — spec 028 widened Article 5 a second time, and Article 5 is the only article that spec changed. Someone holding an invite link now includes a person who is not yet a member (someone who has never signed up and so has never agreed to this policy), and that person is not shown any profile picture. ⚠️ The count stays at 67 and Articles 2, 3, 4 and 6 are unchanged to the letter — no personal information is newly collected (no new tables, no new columns, and the invite secret held during sign-up is never stored on our servers · ADR 021). Rate limiting counts per link only and reads no IP or device, so Article 3 remains true. ⚠️ Widening Article 5 is exactly the kind of change a lawyer must review. It lets a person who has never agreed to any terms see a third party's display name, and this draft has had no legal review (see LEGAL-UNREVIEWED above · SPEC-PLAN C11). 🔺 2026-08-17 — spec 012 raised that count from 67 to 69. Both additions belong to block records — who blocked · who was blocked (Article 2-3 and the "Blocking people you do not want in your plans" row of Article 4). ⚠️ We do not collect when a block was made, when it was lifted, or why — there is no column to hold any of them. ✅ Blocking widens nothing, so Article 5 is unchanged to the letter — blocking narrows what is visible (people you block disappear from each other's "people you have met" list). The Article 6 table also still has 7 rows, because a block record disappears together with the account and has no retention period of its own. ✅ Three things blocking did not add: when you blocked · when you unblocked · why you blocked. None of them have a place to be stored, and the blocked person is never notified. 🔺 2026-08-19 — spec 009 raised that count from 69 to 73. All four additions belong to conversations inside a plan — which plan the message belongs to · who wrote it · the message text · when it was sent (Article 2-2 and 2-3, and the "Providing the plans feature" row of Article 4). ⚠️⚠️ This is the first time the Service stores a sentence a user wrote. A message is free text: whatever you type is stored exactly as you typed it, and we say so in Article 2-2 in the same way we say it for a plan's place. ⚠️ It also widened who can see what — message text is visible to the other participants in the same plan. Article 5 was updated accordingly. Someone who only holds an invite link cannot see it (see the table in Article 5). ✅ Four things conversations did not add: who read a message and when (read receipts) · unread counts · any history of edits or deletions · any connection or device details. None of them have a place to be stored. Article 3 did not change by a single word. ✅ A conversation belongs to its plan. When the plan is deleted, its messages are deleted with it (they follow the "Plan data" row in Article 6 and have no separate retention period). So the Article 6 table still has 7 rows. 🔺 2026-08-20 — spec 009B raised that count from 73 to 78. The five additions are three that make up the notice a plan leaves in its conversation when it changes and two that record how far you have read — what happened · the values that came with it · who did it · how far you have read (time) · how far you have read (message number) (Article 2-3, and the "Providing the plans feature" row of Article 4). ⚠️ "Who did it" holds an account number, not a name, and the field is cleared if that person closes their account — exactly as Conversation — who wrote it already works. 🔺 2026-08-20 — spec 010 raised that count from 78 to 82. All four additions are reactions placed on a message — which message · who reacted · what they chose · when they reacted (Article 2-3, and the "Providing the plans feature" row of Article 4). ⚠️ "What they chose" is not a free-text field — only one of six fixed choices is stored, which makes it different in kind from message text. ⚠️ The range of "who can see it" widened as well — which message you reacted to, and with which emoji, is visible to the other participants in the same plan. We amended Article 5 accordingly. ⚠️ Reactions from someone you have blocked are left out of the count, so the same message can show a different count to different people — that is the result of blocking, not an error. ✅ Three things reactions did not create: a channel for reporting a reaction · emoji outside the six · a history of edited reactions. We built neither the fields nor the paths for any of them. Article 3 is unchanged, to the letter. 🔺 2026-08-29 — this line used to read "four", and the first item was a list of names of who reacted; spec 010B built it, so the count is now three (see the 2026-08-29 entry below). ⚠️ Left as it was, this policy would claim we did not build something we did build. ✅ A reaction belongs to both the message and the account. It is deleted with the message when the plan is deleted, and if the person who reacted closes their account, the reactions they placed are deleted with it. So the table in Article 6 still has 7 rows and no row was added to Article 7 (processing entrusted to others). ⚠️ Whether a reaction counts as "Content" under the Terms of Service was not decided in this spec. Spec 010 did not change a single character of the three Terms documents. That determination needs legal review (SPEC-PLAN C11; see LEGAL-UNREVIEWED at the top of this document). ⚠️ It also widened who can see what — and this time in a different direction. Someone who leaves a plan, or is removed from it, is no longer a participant in it, yet their display name stays visible to the participants who remain, in the notice that announced it. The older sentence ("people taking part in the same plan") does not cover that case, so we added a line to Article 5. ✅ Three things notices did not add: the content before and after a change (the old title, place or time) · who read a message and when (read receipts) · a separate table for notices. None of them have a place to be stored. Article 3 did not change by a single word. ✅ Both a notice and "how far you have read" belong to the plan. A notice sits in the same place as the conversation, so it is deleted when the plan is deleted; how far you have read sits on one row of the participant roster, so it disappears with that row when you leave. So the Article 6 table still has 7 rows and no row was added to Article 7 (processors) either. ✅ We run the real-time delivery software ourselves — it is not handed to another company, so no row was added to Article 7 (processors). ⚠️ We have not confirmed that this reading is correct as a matter of law — it needs legal review (SPEC-PLAN C11), and this draft has not had it (see LEGAL-UNREVIEWED at the top). 🔺 2026-08-21 — spec 016A rewrote the "Device identifier" line in Article 2-3, and that line is the only thing this spec changed in this policy. Before 016A the app invented a new device identifier every time it started, which is why this policy carried a sentence saying the value was created afresh on each launch. 016A made the app keep that value in the device's secure storage, so the sentence stopped being true — and we do not leave an untrue sentence standing, so all three language versions were corrected in the same piece of work. ⚠️ Why we made it persist: under the old behaviour, signing out sent the name of a device that had never existed, so the sign-in key on the server was not actually revoked. Keeping the value on the device is what makes a sign-out really end the session, and it stops the device record from growing by one row on every sign-in. ✅ 016A collects no new personal information — no new tables, no new columns, no migrations, and the item count stays at 82. No new consent is taken, the deletion table in Article 6 still has 7 rows, and no row was added to Article 7 (service providers). ⚠️ The retention period for the 8 devices columns is still undecided — 016A did not decide it (deciding it would make Article 6 an 8-row table). ⚠️ What changed is not what we collect but what kind of value it is. The purpose is unchanged — managing your sign-in state across your devices and knowing where to send notifications — and we do not use it for advertising or tracking and do not hand it to anyone outside the company. The moment we go beyond that, this policy becomes untrue again. ⚠️ Whether a value that now persists on the device counts as a "persistent identifier" is a question for legal review (SPEC-PLAN C11; see LEGAL-UNREVIEWED at the top of this document). ✅ 016A did not change a single character of the three Terms of Service documents. In particular, Article 8(2) of the Terms ("there is no account deletion menu inside the app at present") remains true — 016A did not add any way to delete an account to the settings screen. 🔺 2026-08-22 — spec 011 raised that count from 82 to 88. All eight additions belong to the change history of a plan — which plan it happened on · who did it · who it was done to · what happened · when it happened · which field changed · the value before · the value after (Article 2-3, and the "Providing the plans feature" row of Article 4). ⚠️ "Who" and "to whom" hold account numbers, not names; if that person closes their account those fields are cleared while the history row itself remains — exactly as Conversation — who wrote it already works. ⚠️ 009B listed "the content before and after a change" among the things it did not build; spec 011 built it. It is not inside the conversation, however — the notice left in the conversation still does not carry those values, and a separate change history carries them. ⚠️ Editing a plan therefore leaves the old title and the old place standing in that history. ⚠️ Who can see what did not widen — but one line 009B already widened now covers one more place. The display name of someone who left a plan, or was removed from it, now stays visible in the change history as well as in the conversation notice. We widened that existing line of Article 5 rather than adding a new one. ✅ Five things the change history did not add: a field holding a name · a field holding a finished sentence · an invite link address or its secret · a record of turning attendance on and off · a record of declining an invitation. None of them have a place to be stored. Article 3 did not change by a single word. ✅ The change history belongs to its plan. When the plan is deleted, the history is deleted with it (it follows the "Plan data" row in Article 6 and has no separate retention period), so the Article 6 table still has 7 rows and no row was added to Article 7 (processors). Spec 011 did not change a single character of the three Terms of Service documents. 🔺 2026-08-29 — spec 010B widened Article 5, and Article 5 is the only article this spec changed. Pressing the reaction count under a message now shows who pressed that reaction — their display name and profile picture — and when they pressed it, to the other participants in the same plan. ⚠️ No new personal information is collected and the item count stays at 88 — no new tables, no new columns, no migrations. Two fields we already held, Reaction — who reacted and Time of the reaction (Article 2-3), leave our servers for the first time, and what widened is who can see it, not what we collect. ⚠️⚠️ That is why we rewrote the ✅ line dated 2026-08-20 — the first of the "four things reactions did not create" was a list of names of who reacted, and 010B created it. That line now reads three, and the remaining three (a channel for reporting a reaction · emoji outside the six · a history of edited reactions) are still true. ✅ 010B created no new place to hold anything — the table in Article 6 still has 7 rows, no row was added to Article 7 (processors) (we added no outside service), and the three Terms of Service documents are unchanged, to the letter. ⚠️ Someone you have blocked does not appear in that list either — exactly the same range as being left out of the count — and the app does not say on screen that anyone was left out (saying so would reveal that a block exists). ⚠️ Widening Article 5 is a place a lawyer must look at again — this time participants come to see each other's display names and the times they pressed. This draft has still not had legal review (see LEGAL-UNREVIEWED at the top of this document and SPEC-PLAN C11). We deleted none of those markers. 🔺 2026-09-25 · Spec 009C raised the item count from 107 to 129. The twenty-two new items are eight in report records (who reported · the reported message · the reported person · reason · description · handling status · when it was reported · when handling was finished), nine in moderation records (what was done · who did it · which report it followed · which message · whom it concerned · reason · operator note · hiding period · when it was done), three on a message's state (its current state · when hiding ends · when the state last changed) and two on a notification (the moderation outcome and its reason) (Article 2, 2-3 · Article 4 "Handling reports and moderating content"). ✅ The person who reported is never revealed to the person reported — see Article 5. The table in Article 6 went from 7 rows to 8 — report and moderation records belong neither to a plan nor to an account and have their own retention period (1 year from when handling was finished). Article 3 and Article 7 (processors) are unchanged to the letter — these records hold no connection address or device information, and nothing is entrusted to an outside company. ✅ The two sentences in Article 2 saying a sent message or picture could never be deleted were rewritten to match the facts — the sender can now delete their own messages and pictures (editing still does not exist). 🔺 2026-09-27 · Spec 065 · ADR 045 — the server now keeps a "service usage record" and your "connection IP address" for every request. So the "IP addresses" and "Access logs" rows were removed from Article 3, "Information collected automatically" was added under Article 2-3, one purpose row was added to Article 4, and the Article 6 "operational logs — 1 year" row became "service usage records · connection IP information — 3 months" (still 8 rows). ⚠️ The 008 and 028 notes above — we did not create "when and where a link was opened (access logs)" and "Article 3 is still true because we read no IP or device" — were true at the time. Opening a link is now recorded like every other request, as one service usage record kept for 3 months (the link's secret is not written). The burst limit still does not use IP addresses. ✅ These records live in the server's log files, not in the database, so they are not counted in the item count at the top (129) — that number is tied to the database columns in the personal data ledger. The Terms of Service did not change by a single character. ⚠️ We have not checked whether the law requires keeping these records, whether they may be collected without consent, or whether they fall under access requests — this is an internal review, not a lawyer's (ADR 041 · ADR 045).

The placeholder names below are deliberately left in Korean and are identical across the Korean, English and Japanese versions. Do not translate them. If the names differ between versions, whoever fills them in will miss one.

🔺 2026-09-25 — settled: we run the servers ourselves in the Republic of Korea, and only encrypted backups go to NAVER Cloud, also in Korea. Neither of these is a cross-border transfer. 🔺 The owner confirmed Cloudflare on 2026-09-25 — a processor row and a "Cross-border transfer" section were added to Article 7 under Korea's PIPA art. 28-8(1)3 (disclosure in this policy, no separate consent — ADR 041, decision 3). Actually attaching it is TODO B-4. 🔺 2026-09-25 · spec 002B replaced the placeholder row in the Article 7 table with the NAVER Cloud row.

✅ Repeat settings are not a free text field. 🔺 2026-08-27 — spec 018A: you pick from fixed choices, so nothing you typed is stored verbatim, and one repeating plan may hold between 2 and 52 occurrences. ⚠️ Repeat settings cannot be changed afterwards — the only route is to cancel the remaining occurrences and create a new plan. ⚠️ The plan place is a free text field. If you type something sensitive, such as your home address, it is stored exactly as you typed it. Please enter only what you need to. ⚠️ Message text is a free text field too. If you type something sensitive, such as a phone number or an address, it is stored exactly as you typed it and it is visible to the other participants in the same plan (see Article 5). Please enter only what you need to. ⚠️ The sender can delete their own messages and pictures, but cannot edit them. 🔺 2026-09-25 — spec 009C: once deleted, a message disappears from the screens of all participants in the plan, leaving only a "deleted message" mark, and for a picture the picture file on our server is deleted too. However, it stays in our encrypted database backups for up to 14 days before being removed automatically (Article 7). ⚠️ Messages in a plan you have already left cannot be deleted in the app — please ask us at help@timingle.app. A message you do not delete disappears when the plan itself is deleted (Article 6). ⚠️ Pictures follow the same rule as messages. 🔺 2026-08-26 — spec 017A: if a picture shows a face, or a recognisable place near your home, the other participants in the same plan see it exactly as sent (see Article 5). Please send only what you need to. ✅ Pictures are kept only on servers we run ourselves in the Republic of Korea. We use no outside picture-hosting service, so Article 7 (processors) gains no row for pictures. Like all other traffic, however, pictures travel between your device and our servers through Cloudflare, described under "Cross-border transfer" in Article 7 (it relays them and does not keep them).

✅ Requests made without signing in carry no account identification number. The purposes are in Article 4 and the retention period and deletion in Article 6. ⚠️ Unlike the table above, this information is kept in the server's log files, not in the database. It is therefore not counted in the item count at the top of this policy.

✅ Report and moderation records belong neither to a plan nor to an account. 🔺 2026-09-25 · Spec 009C — they are kept for 1 year from when handling was finished and then deleted (Article 6), and reports not yet handled are never deleted. If the account or the plan is deleted first, the record remains and only the field that pointed at that person or message is cleared. ⚠️ A report's description is a free-text field. Please write only what is needed to judge the report. We do not write this description into our server's operational logs.

⚠️ A "record of a change to a plan" is a notice we generate, not something a user wrote. It is a single line the app draws to say what happened — "the host changed the time" — and it sits in the same place as the conversation. ⚠️ We do not store the content before or after the change (the old title, place or time): storing it would copy free text a user typed into the conversation a second time, and that copy would survive later edits to the plan. 🔺 2026-08-22 — spec 011 created a place for those values outside the conversation — the eight "Change history" rows in the table above — and the notice left in the conversation still does not carry them. ✅ A notice belongs to its plan too. When the plan is deleted, the notice is deleted with it (it follows the "Plan data" row in Article 6 and has no separate retention period), and how far you have read hangs off the participant roster, so it disappears with that row when you leave the plan. ✅ We did not build read receipts — who read this message and when. All that is kept is one "how far have I looked" per person, and other participants cannot see it; we use it only to show you your own unread count.

⚠️ A notification is visible only to the person who received it. We built no screen and no path that shows who received what notification to anyone else — this is where notifications differ from conversation notices and plan change history, which are visible to every participant of that plan (see Article 5). ✅ A notification holds no name, no finished sentence, and no copy of the plan title. We built no field for any of them — the sentence you see is composed by the app in the reader's own language each time. ✅ A notification belongs to both the plan and the account. When the plan is deleted, the notifications about that plan are deleted with it (the "Plan data" row in Article 6), and if you close your account your whole inbox and your notification settings are deleted (the "Account information" row in Article 6). Neither has a retention period of its own. ✅ Notifications you had switched off are not created later when you switch them back on. While a kind is off we do not create the row at all. ✅ Messages do not create notifications. Unread messages are still counted only on the conversation side, and nothing piles up in the notification inbox.

✅ Repeat settings belong to the plan as well. 🔺 2026-08-27 — spec 018A: once no occurrence of a series is left, the repeat settings of that series disappear with them (they follow the "plan data" row of Article 6 and have no retention period of their own). So the table in Article 6 stays at seven rows and Article 7 (processors) gains no row. ⚠️ An uploaded picture belongs to both the plan and the account. 🔺 2026-08-26 — spec 017A: when the plan is deleted, the picture files in that plan's conversation are deleted with it (the "Plan data" row in Article 6), and if you close your account your profile picture and every picture you sent into a conversation are deleted down to the file (the "Account information" row in Article 6). Neither has a retention period of its own. ✅ We store neither the width and height of a picture nor the name of the file you uploaded. We built no field for either. ⚠️ If a picture file cannot be deleted we do not record that erasure as successful; the next run tries again. This is to stop a file surviving on our server while the record says "deleted."

⚠️ The change history records what became what. It sits in a different place from the notice left in the conversation (the three "Record of a change to a plan" rows above), and it carries the values before and after that the notice does not. ⚠️ Once a row is written we cannot alter it — a record of edits that can itself be edited means nothing. ✅ The change history belongs to its plan. When the plan is deleted, the history is deleted with it (it follows the "Plan data" row in Article 6 and has no separate retention period). ✅ Turning attendance on and off, declining an invitation, messages and reactions are not written to the history. We built no place to hold them — doing so would pile up "when did they change their mind" and add one more piece of personal information. ✅ We built no field holding a name, no field holding a finished sentence, and no field holding an invite link address or its secret.

⚠️ A reaction is one of six fixed choices. It is not a field you type into but a choice among like, love, laugh, celebrate, wow and sad, and nothing outside those is stored. What stays on screen is a count per emoji and whether you pressed it yourself — nothing more. ✅ We did not build a list of names of who reacted. The account identifier is stored, but there is no screen and no path that turns it into a name. ✅ A reaction belongs to both the message and the account. It is deleted with the message when the plan is deleted (the "Plan data" row in Article 6), and if the person who reacted closes their account, the reactions they placed are deleted with it (the "Account information" row in Article 6). Neither has a retention period of its own.

⚠️ An invite link belongs to its plan. When the plan is deleted, its links are deleted with it (they follow the "Plan data" row in Article 6; they have no separate retention period). ✅ We do not store which link someone came in through. A person who joins by link appears on the roster as one row exactly like everyone else's, with no record of how they arrived. ✅ We do not create a separate record for each link; like every other request, a service usage record is kept for 3 months ("Information collected automatically" above · Article 6). The link's secret is not written into that record. The counter that limits bursts of requests lives only in server memory, is never stored, and does not use the requester's IP address. 🔺 2026-09-27 · Spec 065

⚠️ A block record is two fields and nothing more. Only who blocked and who was blocked are kept; when you blocked, when you unblocked, and why you blocked are neither collected nor stored. Lifting a block deletes the record rather than flagging it. ✅ The blocked person is never notified. We have built no channel that tells anyone "you have been blocked." ✅ A block record belongs to the accounts it names. If either account is closed and erased, both the record of blocking and the record of being blocked are deleted with it (it follows the "Account information" row in Article 6 and has no separate retention period).

⚠️ The participant roster is a record of relationships between users. It records who is on which plan with whom, and everyone on the same plan can see each other's display name and profile picture (see Article 5). We do not provide any way to search for another user by name or handle. ✅ If someone declines, is removed, or leaves, their row is deleted from the roster. We still do not store who declined an invitation. 🔺 2026-08-22 — spec 011 changed the other half of this sentence. Leaving and being removed are now left as a line in the plan's change history (see the "Change history" rows above), and that line records who removed whom. Declining is still recorded nowhere.

We do not sell your personal information, and we do not share it for cross-context behavioural advertising. In the language used by California and several other state privacy laws, we do not "sell" or "share" personal information, and we have never done so. There is therefore no "Do Not Sell or Share My Personal Information" mechanism to offer — because there is nothing to opt out of. ⚠️ We have not verified whether a state requires the link to be displayed even when nothing is sold.

Sensitive personal information. Several state laws define a special category of "sensitive" personal information. We do not collect precise geolocation, racial or ethnic origin, religious beliefs, health data, sexual orientation, biometric data, or government identifiers. ⚠️ We have not confirmed how each state classifies a date of birth.

⚠️ Two users who have blocked each other do not see each other's messages. If either one blocks the other, neither sees the other's messages, and messages written before the block are hidden too. Unblocking brings them back — they are hidden, not deleted. ✅ The blocked person is not told. Their message is sent normally; it is hidden only on the receiving side.

⚠️ Anyone holding the link can see this. We do not check who is holding a link, so if the link is forwarded, whoever receives it can see the above. The person who made the link can narrow this themselves — by setting an expiry and a limit on how many people may join, or by revoking the link at any time.

⚠️ Narrowing what leaves us is the defence available to us today. We narrowed what the card carries to a single name, and the response for that page asks anything in between not to store it (Cache-Control: no-store). Even so, once a card has been built we have no way to take it back — where a link is posted is decided by the person posting it.

Why we wait 30 days after termination: it is the minimum period we need to process the termination request, deal with enquiries or objections raised around that time, and check for abuse. Your account cannot be restored during this period, and after 30 days it is deleted irreversibly.

⚠️ This creates a tension with your deletion rights under state privacy law. Most of those laws allow an exception where information must be kept to comply with a legal obligation or to establish a legal claim. We have not verified that our 5-year consent history falls within that exception in any particular state. See Article 10, paragraph 4.

⚠️ Draft-only note (delete before publishing) — which rows of this Article are facts today: 🔺 2026-08-11 · Spec 025 · 🔺 2026-08-15 · Spec 027 Count: of 8 rows, 6 are facts · 0 half · 2 still a promise. 🔺 2026-09-25 · Spec 009C — the sixth fact is report and moderation records, 1 year. The same spec put that kind into the deletion command, which removes reports whose handling finished more than a year ago together with the moderation records attached to them (a moderation record with no report is removed one year after it was made). Reports not yet handled are never deleted. Now facts (5): terminated accounts 30 days · consent history 5 years · expired sign-in sessions 30 days · date-of-birth change attempts 90 days · plan data. The "How we delete" and "Some records cannot be deleted" paragraphs above now match the actual behaviour — consent history cannot be altered at all, regardless of age, cannot be emptied wholesale, and only records older than 5 years can be deleted. How the plan-data row became a fact: when an account is erased, each plan that account created is checked for other remaining participants. If any remain, the plan is kept and only the creator's identity is cleared (anonymisation — the departing person's name, email address and profile picture are left nowhere in that plan). If none remain, the plan is erased together with the account. The two steps run in a single transaction, so no half-deleted state is left behind. ⚠️ One paragraph of the old draft note was deleted here on 2026-08-15. It said, in effect, that there was nothing to anonymise yet; spec 007 (plan participant roster), shipped the same day, let a plan hold several people and made that claim untrue. Spec 027 removed the paragraph and wrote the real behaviour above instead. It is not a sentence to restore — restoring it would mean removing the participant roster. 🔺 2026-08-20 — spec 009B added notices and "how far you have read", and this table still has 7 rows. The "Plan data" row covers both of them — a notice sits in the same place as the conversation and is deleted when the plan is deleted; how far you have read sits on one row of the participant roster and disappears with that row when you leave. Neither has a retention period of its own. ⚠️ No new deletion category was created — one would have made this table 8 rows and changed the denominator of the "5 of 7" the user approved in spec 025. ⚠️ If the person who caused a notice closes their account, the notice stays and only the "who did it" field is cleared — the same thing spec 027 already does for plans and spec 009 for messages. 🔺 2026-08-19 — spec 009 added conversations, and this table still has 7 rows. The "Plan data" row covers conversations — a message belongs to its plan, so it is deleted when the plan is deleted and has no retention period of its own. ⚠️ No new deletion category was created — one would have made this table 8 rows and changed the denominator of the "5 of 7" the user approved in spec 025. ⚠️ If the person who wrote a message closes their account, the message stays and only the author field is cleared — the same thing spec 027 already does for plans. 🔺 2026-08-20 — spec 010 added reactions on messages, and this table still has 7 rows. The "Plan data" row covers reactions — a reaction hangs off a message and a message hangs off a plan, so deleting the plan deletes the reactions with it. ⚠️ And the "Account information" row covers the other half — if the person who reacted closes their account, the reactions they placed are deleted with it. Neither has a retention period of its own. ⚠️ No new deletion category was created — one would have made this table 8 rows and changed the denominator of the "5 of 7" the user approved in spec 025. ⚠️⚠️ This is the exact opposite of a message: when an author closes their account the message stays and only the name is cleared, but a reaction has nothing left once the name is gone, so the row itself disappears and the count on that message goes down. ~~Still promises (2): operational logs 1 year (…) · payment records 5 years (no payment feature).~~ 🔺 2026-09-27 · Spec 065 — Still a promise (1): payment records 5 years (no payment feature). Count: of 8 rows, 7 are facts · 0 half · 1 still a promise. The seventh fact is "operational logs — service usage records · connection IP information, 3 months" — the server writes these records to a fixed folder (/var/lib/timingle/access-log) as one file per day and deletes files older than 90 days at start-up and once a day. These records are not written to the server's general log (which is cut only by a 20 MB size cap). ⚠️ If this folder is backed up, the copy outlives the 90 days and this row becomes false — we do not back it up. This is an internal review, not a lawyer's (ADR 041 · ADR 045). ⚠️ The second reason given above for the 30-day wait (stopping people from evading restrictions by re-registering) does not hold in the current design — when a sign-up is refused on age grounds the social link is severed immediately, so re-registration is possible the next moment (spec 024). Rewording is legal counsel's call (C11) and was deliberately not done here. 🔺 2026-08-22 — spec 016B: ⚠️⚠️ the first reason (giving someone who closed their account by mistake a chance to undo it) no longer holds inside the app either. Spec 016B added Delete account to the Settings screen but did not build any way to undo it — signing in again with the same social account creates a new account instead of restoring the old one (exactly as spec 025 decided when it chose not to build restoration). ⚠️⚠️ So neither of the two reasons written above for the 30-day wait holds. ⚠️ The body of Article 6 (the table and its text) was still not changed by a single character — the 30 days really do work that way, and how the sentence should be reworded is legal counsel's call (C11), so 016B only records the fact here and hands it over. 🔺 2026-09-25 — the "why we wait 30 days" wording above was corrected (ADR 041, decision 5 · Claude's internal review, not a lawyer's). It now matches the fact that there is no way to restore an account; the 30-day behaviour itself is unchanged. ⚠️ Whether a 30-day hold with no restore sits comfortably with "delete without delay" (PIPA art. 21) is open question 9 in ADR 041.

⚠️ Draft note — delete before publishing: 🔺 The owner confirmed Cloudflare on 2026-09-25, and this section was added at that point (ADR 041, decision 5 · wording from review ② §2-⑥). ⚠️ Cloudflare's address, contact and retention period must be checked against Cloudflare's privacy policy before publishing. ⚠️ Publishing before Cloudflare is actually in front of the servers (TODO B-4) would make this section untrue — publish after it is attached.

⚠️ Draft note — delete before publishing: 🔺 2026-09-25 · ADR 041, decision 5 — the values are settled. We run the servers and database ourselves in the Republic of Korea (ADR 026); only encrypted database backups are entrusted to NAVER Cloud Corp. (Republic of Korea) and deleted after 14 days (ADR 027). 🔺 2026-09-25 · spec 002B — the placeholder row in the table above now states that fact ("NAVER Cloud Corp. — storing encrypted database backup files — in the Republic of Korea"), and the sentence above the table says we run the servers ourselves in the Republic of Korea. 🔺 The owner confirmed Cloudflare on 2026-09-25, so a processor row and a "Cross-border transfer" section were added (attaching it is TODO B-4). Under Korea's PIPA art. 28-8(1)3 (in force 2023-09-15) a transfer for processing or storage is disclosed in this policy rather than consented to separately.

⚠️ How this relates to COPPA — read before publishing

The Children's Online Privacy Protection Act (COPPA) protects children under 13. Our threshold of 14 sits above that line, so on its face no child COPPA covers can register.

That does not by itself make us compliant. COPPA turns on whether a service is directed to children and on what the operator actually knows — not only on a stated age limit — and we accept a self-declared date of birth that we never verify. ADR 015 removed children from the first release and relies on this age gate as the defence, but that decision was made without legal advice. SPEC-PLAN.md item C11 records the open question directly: whether a self-declared age gate is sufficient in each jurisdiction, and what evidence is needed to show that we do not target children.

We have not re-verified COPPA's current requirements. ADR 005 records that a 2025 amendment took full effect on 2026-04-22, expanding the definition of personal information to include biometric data and adding separate consent requirements for targeted advertising and AI training. Confirm the current rule before publishing.

Separately, several state laws give additional protection to minors under 16 or 18 — for example limits on profiling and on targeted advertising. We do neither, but we have not surveyed those laws.

The Service has no paid features today. What follows applies once paid services exist.

⚠️ Most US states require notification if personal information is exposed in a security breach, and the deadlines and thresholds differ by state. We have no breach notification procedure written down. This is not something the policy text can fix; it needs a procedure. Flagged for legal review.

We handle enquiries by email. We do not operate a customer support telephone line.

We handle enquiries and complaints by email only. When we start offering paid services, we will add the representative's name, business address, telephone number and business registration number here, as Korea's Act on Consumer Protection in Electronic Commerce requires.