Privacy Policy
This Privacy Policy explains what personal data the Service collects, on what legal basis it is processed, how it is used, where it is stored, with whom it is shared, how long it is retained, and what controls you have. It applies to all visitors of needmoretruth.com regardless of location. Two design choices shape the rest of this document: the Service stores no raw IP addresses, and the values it does store for anti-spam purposes are computed under a daily-rotating random salt that is irrecoverably discarded each UTC day, so that the Operator cannot link those values across day boundaries. Capitalised terms used but not defined in this Policy have the meaning given to them in the Terms of Use.
Last updated: 2026-08-22 · Version: 2026-08-22-v26
Your right to object
Where the Operator relies on its legitimate interests — the categories are named in Section 3 — you may object at any time, on grounds relating to your particular situation, and you do not have to give any other reason. Write to [email protected], or use the in-Service Support or Bug & Operations Reports channel, and say what you object to. The Operator either stops that processing or explains why it must continue, and answers you. Objecting costs nothing and carries no disadvantage. The Operator answers within one month where the GDPR applies and within ten days where the Korean Personal Information Protection Act applies; an objection to an automated decision has its own deadline, in Section 12. They differ because different laws set them, and where more than one reaches you the Operator works to the shorter. Section 11 sets out this right in full.
1. Summary
The Service processes personal data to the extent needed to run a community board and to keep abuse out. What is stored is listed category by category in Section 4, and that list is the most important part of this Policy. The Service does not store raw IP addresses, does not sell personal data, does not display third-party advertising, and does not store passwords. Account data is sourced from your sign-in provider (GitHub). IP-based anti-spam keys are not stored as conventional salted hashes but as one-way HMAC values computed with a daily-rotating random salt that is irrecoverably discarded at the end of each UTC day, so that the Operator cannot — even with full database access — derive yesterday's IP-based identifiers from today's. You can delete your account yourself from the Account area of the settings page, and you may also request deletion through the in-Service Bug & Operations Reports channel. Note that posts and comments you already published are not deleted: the author name is replaced with an erased marker and the link to your account is cut.
2. Data controller
The Operator is the data controller (the "personal information controller" under the Republic of Korea Personal Information Protection Act) for the personal data processed in connection with the Service. The Operator provides the Service from the Republic of Korea (대한민국). One person runs the Service; it charges no fee and carries no advertising. Consistent with the data-minimisation design of the Service, the Operator does not publish a personal legal name, postal address, or business-registration number, and discloses instead the country of establishment together with the contact email below. Under the Korean Personal Information Protection Act, the person responsible for personal-data protection is the Operator personally: Article 31(2) provides that where no such person has been designated, the controller's representative or owner holds the role. Article 30(1)(6) of the same Act asks a privacy notice to carry either the name of that person, or the name of the department that handles personal-data work and complaints together with its telephone number and other contact details. Neither limb is met by what is published here. The Operator does not publish a personal legal name; there is no department, because one person runs the Service; and no telephone number is published. What is published instead is one email address that reaches the Operator personally — [email protected] — alongside the in-Service Support and Bug & Operations Reports channels. The Operator does not claim that this satisfies Article 30(1)(6). It is what one person running a free service can offer without publishing a home address or a personal telephone number, and every request sent there is read and answered by the Operator personally. You can contact the Operator about this Policy or to exercise your rights at that address, or through the in-Service Support or Bug & Operations Reports channels. No separate Data Protection Officer within the meaning of GDPR Article 37 has been appointed, because none of the three cases in which that Article requires one applies here (a public authority, large-scale regular and systematic monitoring, or large-scale processing of special categories). The Operator handles every data-subject request personally. The Operator has not appointed a representative in the European Union or the United Kingdom under Article 27 of the EU/UK GDPR. Article 27(2)(a) lifts that obligation where the processing is occasional, does not include large-scale processing of special categories of data or of criminal-conviction data, and is unlikely to result in a risk to people's rights and freedoms — all three at once. The Operator does not claim that exemption, and equally does not concede that Article 3(2) is engaged; that question turns on whether the Service targets people in the Union, and the Service is offered in Korean and English from Korea to whoever finds it, with no marketing, no currency, no shipping and no country targeting. What is certain is the plain fact: no representative has been appointed, because one person runs the Service without charging for it and cannot carry the cost. If a supervisory authority takes a different view, the Operator will deal with it directly at the address above. No legal representative under Article 13 of the EU Digital Services Act has been appointed either. That Regulation requires two separate points of contact and both of them are the email address above. Article 11 requires one for Member States' authorities, the Commission and the Board. Article 12 requires one for users of the Service, who may equally use the in-Service Support or Bug & Operations Reports channels, so that reaching the Operator never depends on an automated tool alone. As Article 11(3) requires, the language that may be used with these points of contact is English; Korean may also be used. EU/EEA and UK data subjects retain every right described in this Policy and may at any time contact the Operator directly at the email above and lodge a complaint with their local supervisory authority (Section 11).
3. Lawful basis for processing
The Service processes personal data on the following lawful bases under applicable law (including, where relevant, EU/EEA GDPR Article 6, UK GDPR, the Korean Personal Information Protection Act (PIPA), the California Consumer Privacy Act and California Privacy Rights Act (CCPA/CPRA), and equivalent regimes elsewhere): (a) performance of the User-Operator agreement constituted by the Terms of Use; (b) the Operator's legitimate interest in preventing abuse, fraud, and security incidents, in operating the Service safely, and in understanding overall usage of, and maintaining and improving, the Service (including through the aggregate, cookie-less analytics described in Section 7); (c) compliance with applicable legal obligations to which the Operator is subject; and (d) the User's explicit consent obtained via the consent gate before any processing for which consent is the appropriate legal basis. Which basis carries which category of Section 4: account details and what you post, direct messages, saved posts, lists, hidden words and channel-level consents rest on (a), performance of the agreement. Abuse-prevention values (IP-derived hashes, rate limits, automatic blocks), the audit log, channel-level blocks and their reason notes, reading history, and channel-moderator roles and evaluations rest on (b), legitimate interests. Archive deposits rest on (b) alone: a deposit can be left without an account, so there is no agreement to perform, and the interest is the plain one of receiving material somebody chose to send the Operator. That is the hardest balance on this page, because a deposit is a whole file the Operator can open, it may name people who never sent anything, and the depositor is not identified — so the limits the Operator accepts are part of the balance and not a courtesy. It opens a deposit only so far as is needed to answer a specific question put to it, keeps no listing and no index of what is inside, publishes nothing, deletes a deposit when the depositor or a person named in it asks (Section 29 of the Terms), and deletes what is left at the twelve-month review. With those limits the interest is a narrow one that does not override the rights of the people concerned; without them it would not be, and the Operator would have to stop taking deposits rather than widen it. The remaining categories of Section 4 are these. The viewer cookie, the Guest label on a submission, sanction records, ban appeals, notification records and post-move requests rest on (b) — keeping the board usable, being able to show what was done, and answering the person who wrote in. The name and address somebody leaves on a content report or a ban appeal rest on (b) as well, and the interest is stated exactly: being able to answer them, which is what Article 16(4) and (5) of the EU Digital Services Act require of a notice mechanism. Blocks and follows between members rest on (a): they are features you asked for as a Member, and without them the feature does not work. A Guest has no account and no agreement to perform, so the deletion password a Guest sets on their own post rests on (b), and the interest is the Guest's own — being able to take back what you wrote without an account. The record of which versions of the Terms and this Policy you accepted rests on (a): it is the record of the agreement itself, which is what makes it possible to say which text binds you and which text the Operator must honour. Anything the law requires to be kept rests on (c). Some personal data does not come from you. That is true of a person placed in a list another member made, a moderator who has been evaluated, a person named in a channel-level block record, and a person named inside a file someone deposited in the Archive. The basis is (b), legitimate interests, and the source is the other user who created that material. Who that user is, is decided item by item on the same balance as access in Section 11 — where it is withheld you are told that it was withheld and why. What the Operator does about telling those people is stated here rather than left open. For a person named inside a deposit the Operator holds no identity at all and cannot reach them. For the other three, telling the person would defeat the thing itself: telling somebody that another member put them in a private list turns the list into a message aimed at them, which is exactly the harm the design avoids, and the same is true of a channel-level block note. The Operator therefore relies on Article 14(5)(b) of the GDPR for all four, and the measure that provision requires in its place is this: this Policy is public, it names the four groups, the categories held about each are set out in Section 4, the retention is in Section 10, and every right in Section 11 — including erasure and objection — is open to them on the same terms as to anybody else, through the contact routes in Section 11. Where the basis is (b), the interest is named here rather than left as a label. Abuse-prevention values, rate limits and automatic blocks: keeping the board usable and keeping spam and repeated abuse off it. The audit log: being able to reconstruct what an administrator or a moderator did, which is what makes a moderation action contestable at all. Channel-level blocks and their reason notes: letting a channel moderator apply that channel's rules consistently and show why. Reading history: showing you what is new since you last looked, which is the only thing it is used for. Channel-moderator roles and evaluations of moderators: knowing who holds a role, and letting members say how it is being used. In every case the interest is the Service working as a board at all, and it is weighed against your rights each time you object — see the objection paragraph in Section 11. What you must provide, and what happens if you do not. An account cannot be created without the profile the identity provider returns and the tokens that keep you signed in; that is the whole of what is required, and without it there is no account. Everything else in Section 4 comes from using a feature you chose to use. Declining any of those features costs you nothing but the feature itself: you can read the whole public site with no account at all, and you can post as a Guest.
4. Categories of personal data we store
(a) Account profile data received from your sign-in provider: provider name (GitHub), provider account ID, login name, public display name, optional short display-name suffix of letters and digits, avatar URL, and email address where exposed by the provider. The OAuth access and refresh tokens issued by the sign-in provider are also stored so that your signed-in session can be maintained; they are not used for any purpose other than authentication. (b) Content you submit: post titles and bodies, comment bodies, reactions, content reports, support tickets, and bug & operations reports. A content report also carries what the report form asks for and you choose to give — a name and an email address, both optional — kept for one purpose only, so the Operator can confirm receipt and tell you what was decided. The Operator deletes the address the moment it has answered, and in any event when the report is cleared out (Section 10). Nothing forces you to give either: leave both blank and the report is still filed, and there is then nowhere to answer. (c) For Guest submissions and Member submissions made in Guest Mode only, an HMAC-SHA256 value of the request IP computed with the current day's random salt — used as a cooldown, deduplication, ban, and audit key. The salt is rotated at the end of each UTC day and the previous salt is irrecoverably discarded, so the value cannot be linked across day boundaries even with full database access. Member submissions do not have an IP-derived value stored against them at all; the Account identifier already serves the moderation purpose. (d) Raw IP addresses are not stored. (e) An opaque random viewer identifier cookie used to count unique post views. (f) The publicly displayed Guest identifier shown as "Guest #CODE"; the code is the first ten base-36 digits of the HMAC value in (c) and is therefore tied to the current day only. The Operator cannot reverse the code into an IP and cannot link a code observed on one day to a code observed on another day. (g) Audit-log entries describing automated and manual moderation actions, including the actor, the target, and — for entries that relate to a Guest action, to a Member action carried out in Guest Mode, or to an IP-level access restriction — the current day's IP HMAC. Audit entries that relate to a Member action made under the Member's Account do not include an IP HMAC; the Member identifier is sufficient for moderation review. (h) A record of your acceptance of the current Terms of Use and Privacy Policy versions, stored against your Account if you are signed in or in a first-party browser cookie if you are not. (i) For Guest submissions and Member submissions made in Guest Mode, a one-way bcrypt hash of the deletion password set at write time. The original password is never stored; the hash cannot be reversed. This data is deleted when the associated submission is deleted. (j) For Member sanctions, an internal record of any active access restriction (Account-level write timeout, suspension, or termination) including its stated reason and duration. (k) Ban-appeal submissions: when a User submits a ban-appeal form, the following are stored so the Operator can answer — the body of that submission; a contact address, if you choose to give one, which is optional and is the only way to answer somebody who is not signed in; the Account identifier, if you are signed in; and the day-scoped IP value described in (c), which is what ties the appeal to the restriction it is about. The contact address is deleted the moment the Operator answers, and the appeal itself is cleared out afterwards (Section 10). (l) In-app notification records: where a Member-visible notification is generated (for example, when a post on which the Member has commented is removed, when the Operator replies to a Member's bug or operations report, or when a restriction is placed on the Member's content or account), the notice is stored so the Member can read it. Marking a notice read does not delete it — a restriction notice is the only copy the Member has of why, so clearing the list must not destroy it. A notice is kept until the Member deletes it, until the Member's Account is deleted, and in any event no longer than three years from the day it was written (Section 10). (m) Software version-history entries (update log): the Operator records internal notes about software updates in a log visible only to the Operator. These entries do not contain personal data and are retained for as long as the Operator considers them useful. (n) Relationship data set by a Member: the block and follow relationships a Member creates between their Account and other Members' Accounts, stored so that the Service can apply the Member's blocking and following choices. (u) Direct messages: the text of messages exchanged only between Members, who sent each one and when, and, per conversation and per person, the time each last read it and the time each hid it from their own list. Message text is stored unencrypted, so the Operator, who can reach the server's data, is technically able to read it. The Service has no feature for reporting a direct message and no administrator screen for reading one. The Operator reads the text of a direct message only where a lawful warrant or court order requires it; when fixing a fault, only envelope values such as identifiers, times and sizes are looked at, not the text. Section 28 of the Terms of Use states the same rule and the audit and notification duties that go with it. (v) Archive deposits: files and notes submitted through the code-gated feature that opens at a separate address. A deposit is encrypted to the Operator's public key before storage; the matching private key is held by this Service's server, so the Operator is able to open it. The file name, size, and time of deposit are stored with it. (w) A Member's reading history: a pair of Member identifier and post identifier, kept so that repeated views by the same Member count once. (x) The list of posts a Member has saved. Saving is not visible to anyone else and is not counted anywhere. (y) Lists a Member has created: the list name, whether it is private, and the identifiers of the Members placed in it. Members placed in a list are not told. (z) Words a Member has chosen to hide. (aa) Channel-level consent records: where additional terms apply to a particular channel, the fact that the User agreed in that channel and when. (bb) Channel-level block records: the fact that a User's writing was blocked in a particular channel, when, and any internal reason note left by the Operator or a channel moderator. Reason notes are not published. (cc) Channel-moderator records: the fact that a Member holds or held a channel-moderator role and for how long, and evaluations Members have left about a channel moderator. (dd) Post-move requests: the fact that a Member proposed moving their own post to another channel, or answered such a proposal, and when.
5. Categories of personal data we do NOT store
The Service does not store: raw IP addresses; passwords; payment information; precise geolocation data; advertising identifiers; biometric data; government-issued identifiers; or, among the items the Operator asks you for, any category designated "sensitive" or "special category" under applicable law. What you type yourself is another matter: nothing stops you from putting anything into your own words, and direct messages and the Archive are where that is most likely. The Operator does not ask for such material, does not classify it, and does not decide anything on the basis of it — but does not pretend it is absent once stored. You are safer not putting it there. Where such material is stored, this Policy does not claim your consent for it. Anything you post on a public surface you have manifestly made public yourself, which is the condition in GDPR Article 9(2)(e). For a direct message or an Archive deposit there is no condition to point to, and this Policy does not invent one. Nobody asked you for consent, and a choice made after reading two sections of the Terms is not the explicit consent Article 9(2)(a) requires; Article 9(2)(f) covers the making of a legal claim, not the storing that happens long before any claim exists. Korean law is narrower still: Article 23(1) of the Personal Information Protection Act admits two gateways only — separate consent, obtained apart from consent to ordinary personal data, or a provision of law that requires or permits the processing — and neither is present here. So the Operator does not treat any of this as permission, and does not describe it as a lawful exception. What it does instead is hold back. It does not ask for such material. No screen in the Service shows the Operator a direct message; reading one would mean working on the database by hand, which the Operator does only under a warrant or a court order (Section 28 of the Terms). It does not classify or index such material, does not use it to decide anything, and deletes an Archive deposit when you ask. Where such material is about somebody other than the person who wrote it, the Operator does not seek it, deletes it when it becomes aware of it, and Section 29 of the Terms gives anyone the route to ask for that. A conversation is stored only while both accounts exist — deleting either account deletes the whole conversation, both sides' messages with it. Posts are treated the opposite way (Section 11), and the difference is how many people are involved: a conversation has exactly two, each of whom already holds all of it, while a public thread has an open-ended set of people whose own writing would come down with yours. The Service does not perform behavioural profiling for advertising purposes. The live database retains no IP-derived value beyond the current UTC day. A backup is a point-in-time copy, so the values that existed when it was taken remain inside it until that bundle rotates out (Section 10).
6. Daily salt rotation and the data-minimisation design
Anti-spam, deduplication, ban, and audit keys derived from a User's request IP are computed using HMAC-SHA256 with a random 256-bit salt stored in an in-memory cache. At the end of each UTC day, the previous day's salt is discarded and replaced with a new random salt. Once a salt is discarded, neither the Operator nor any third party can recover it; the corresponding HMAC values become permanently unlinkable to the IP addresses that produced them and to any HMAC values produced under any other salt. This design is intentional. It means that: (a) an IP-level access restriction ("IP ban") cannot meaningfully bind beyond the current UTC day; (b) the Operator cannot, on request from a User, identify or recover that User's past Guest submissions across day boundaries, because no link exists in the database; and (c) the Operator cannot, on request from law enforcement or any other third party, provide a User's IP address or a value derivable from it, because the Service neither stores raw IP addresses nor retains the salt necessary to recompute prior-day HMAC values. The intent of this design is to comply with the minimisation principles of the Korean Personal Information Protection Act (PIPA) and the EU/EEA GDPR by limiting the Operator's ability to know more than is necessary for the safe operation of the Service. The trade-off is that determined attackers who rotate their network paths cannot be excluded by IP-level restriction alone; the Operator accepts that trade-off and relies on Account-level measures, narrow automated filtering, and the third-party human-verification challenge to maintain Service integrity.
8. Third-party processors and recipients
The following third-party providers may process technical metadata or personal data in connection with the Service and act as their own controllers and/or processors under their respective privacy policies: GitHub (authentication); Cloudflare (DNS, edge, TLS termination, tunnelling between the public internet and the origin server, the Turnstile human-verification challenge, and the object storage that holds the off-site copy of the database backups). Of these, backup storage is work the Operator entrusts to a provider. For that part the Operator is responsible for choosing and supervising the provider and answers to you for what the provider does; What is entrusted is set by the Operator, not by the provider: one copy of the database backup a day, kept for the period stated in Section 10, for restoring the Service and for testing that a restore works, and for nothing else. The provider's data-processing addendum records the safeguards that apply to that instruction; it does not define the instruction. Authentication (GitHub), by contrast, is a relationship you have with that provider directly, and it acts as its own controller for its part. The Operator does not determine how that part is handled, so please consult that provider's own policy. Some personal data is also seen by other Users. A channel moderator or deputy moderator sees how many reports are open in the channel they moderate — a number, not the reports themselves and not who made them — and can see, hide, unhide and pin content there, including content that is hidden from everyone else in that channel. They also see the title, an excerpt and the stated reason of any request to move a post into their channel. They cannot open a report or learn who reported anybody. Moderators are unpaid volunteers who are ordinary Members. Their legal position is stated rather than left open: they are persons acting under the Operator's authority within the meaning of Article 29 of the GDPR, and 개인정보취급자 under Article 28 of the Republic of Korea Personal Information Protection Act. They are not separate controllers and not processors — the Operator remains the controller for everything they touch, and answers for it. They act on the Operator's instruction and are bound by the Code of Conduct published at /conduct; Section 7 of that Code obliges them to use what they see only for the role, not to disclose it or pass it on, and that obligation continues after the role ends. The Operator can withdraw the role at any time. What a moderator can reach is limited to the channel they moderate: no moderator can read direct messages, open Archive deposits, or see the audit log.
9. International data transfers
The origin server is operated in the Republic of Korea. The Cloudflare network and the OAuth identity providers (GitHub) operate globally, so using the Service from outside Korea will involve the transfer of technical metadata and account data to or through other jurisdictions, including the United States. By using the Service from outside Korea you acknowledge that your personal data may be processed in jurisdictions whose data-protection regimes may differ from your own. For transfers of personal data out of the EU/EEA or the United Kingdom, the relevant providers act as the exporting parties and rely on their own transfer mechanisms — principally the European Commission's Standard Contractual Clauses (and the UK Addendum) and, where applicable, an adequacy decision or the EU-U.S. Data Privacy Framework; details are set out in each provider's own privacy documentation (GitHub and Cloudflare). In addition, the Operator keeps a copy of the database backups off-site. That is storage of personal data abroad, so the details are published here as Article 28-8(1)3 of the Korean Personal Information Protection Act requires. What is transferred: everything listed in Section 4 of this Policy, as it stood when the copy was taken. Where, when and how: once a day, uploaded over an encrypted connection to Cloudflare's object storage. Which country: the storage region is set to Asia-Pacific, but a region setting is a placement request rather than a guarantee, and the provider's binding jurisdiction restrictions cover only the European Union, the United States and the US federal FedRAMP environment — there is no Asia-Pacific or Korean option to choose. The consequence is stated plainly rather than papered over: the Operator does not know, and has no means of determining, which country any given copy is held in. Cloudflare, Inc. decides that. What the Operator can state is that the copy may be held outside the Republic of Korea, that it is uploaded over an encrypted connection, and that the recipient is bound by the contract described below wherever it holds the copy. It does not state more than that, and in particular it does not represent that it has assessed the law of the country of destination, because it does not know which country that is. This is a limitation of the arrangement, and the Operator treats it as one to remove rather than one to live with; until it is removed, the paragraph below sets out what you can do about it. Who receives it: Cloudflare, Inc., 101 Townsend St., San Francisco, CA 94107, United States. Its data protection officer is reachable at [email protected], questions about safeguards at [email protected], and rights requests at [email protected]; its transfer documentation is published at https://www.cloudflare.com/trust-hub/gdpr/. Purpose: restoring the service if the origin server is lost, and checking that such a restore actually works. Retention: an off-site copy is deleted ninety-one (91) days after it is written. That is enforced by a lifecycle rule on the storage itself, not by a script the Operator has to remember to run. How to refuse: this copy is a backup of the whole service and cannot be made with one user left out, so there is no setting that excludes you from it. That is a limit of the mechanism, not a refusal of your right. You may object to this processing at any time on grounds relating to your particular situation, by writing to the contact in Section 2; the Operator will either stop the processing you object to or explain the compelling legitimate grounds for continuing, and will answer within one month. Where the Republic of Korea Personal Information Protection Act applies, an objection of this kind is a demand to suspend processing under Article 37 of that Act, and the answer has two halves because the copies do. For everything made from now on the Operator suspends without delay: your data stops going into any copy taken after the demand. For copies already written it cannot suspend, because a backup is a point-in-time copy and one person cannot be lifted out of it. As to those the Operator declines, on the ground in Article 37(2)(4) of that Act — that suspension would make it impossible to perform the agreement to provide the Service — and tells you that ground and how to contest it within ten days, as Article 37(4) and its Enforcement Decree require. If you tell the Operator you are ending that agreement, which means deleting your Account, the ground falls away and only the first half is left. Refusing has no other consequence. Deleting your Account is worth stating exactly, because it does not reach everything: your account data and your direct messages leave the live database, so they are in no copy taken after that; posts and comments you leave behind stay up, and a sanction record stays for the period in Section 10, and both keep appearing in later copies until they too are deleted — Section 11 explains why posts are treated that way and gives you the route to have them deleted. Data already inside a copy is deleted when that copy reaches ninety-one (91) days off-site, or when its bundle rotates out on the origin disk. To the extent data of users in the EU/EEA or the UK is included: no adequacy decision is relied on for this transfer, and the Operator does not claim that one covers it. The recipient is a United States entity, and the safeguard relied on is the European Commission's Standard Contractual Clauses (GDPR Article 46(2)(c)), which form part of that provider's data-processing addendum. Because the country of destination is not determinable, the Operator has not completed the assessment that Clause 14(b) of those Clauses calls for, and says so here instead of warranting an assessment it has not made. If you are in the EU/EEA or the UK and you do not want your data in this transfer while that is the position, you may say so to the contact in Section 2, and the Operator will act on it the only way the mechanism allows — by deleting your account, which keeps your account data and your direct messages out of every copy taken after that. It does not reach posts and comments you leave behind; Section 11 gives the route for those. A copy of the Standard Contractual Clauses that apply to this transfer can be obtained by writing to the contact in Section 2; the Operator will send the version in force, with commercial terms that are not part of the safeguards removed. The provider also publishes its own data-processing addendum, which contains those Clauses, at https://www.cloudflare.com/cloudflare-customer-dpa/. The Operator does not itself export personal data to any further third party beyond these providers.
10. Data retention
Account profile data is retained while your Account is active. You can delete your own Account from the Account area of the settings page, and you may also request deletion through the email contact, the Support channel, or the Bug & Operations Reports channel. By either route the Operator deletes your Account profile data, except for fields that the Operator must retain to satisfy a legal obligation or to resolve an open dispute. Posts and comments are retained until they are deleted by the User, by the Operator, or under any periodic retention policy that may be in force. IP-derived HMAC values stored against Guest submissions and audit entries become unlinkable at most twenty-four (24) hours after creation through salt rotation and are not separately deleted; older values become indistinguishable random strings. Database backups are made daily and kept on the same physical disk as the origin server — not a separate disk. Retention runs in three tiers: the newest thirty bundles, one per week for twelve weeks, and one per month for three months. The longest-lived bundle is therefore about three months. A backup is a point-in-time copy, so one person's data cannot be picked out of it. What you ask to have deleted stays inside a bundle until that bundle is deleted. To shorten that window, the monthly tier was cut from twenty-four months to three on 22 August 2026. During that window the copy is used for nothing but restoring and restore-checking, and if the service is ever restored from a backup, the Operator re-applies the deletion requests it holds outside the database and posts a notice in the Service that a restore has happened, so that a deletion made inside the Service after the copy was taken can be made again. There are three kinds of copy and they are not deleted by the same mechanism, so each is stated separately. (a) The dated bundles on the origin disk: deleted by the three-tier rotation above, longest-lived about three months. (b) The off-site copy: once a day the newest bundle is copied to the object storage named in Section 8, and each such copy is deleted ninety-one (91) days after it is written, by a lifecycle rule on the storage itself. The storage also refuses deletion of anything younger than ninety days — that refusal is a lock the Operator set, to stop an attacker who reaches the account from wiping the backups, and it cannot be waived for one object. So when you ask for erasure and a copy of your data is inside an off-site object younger than ninety days, the Operator cannot delete it there. There is no legal exception to claim for that, and this Policy does not claim one. Article 17 of the GDPR gives no ground for keeping a copy because deleting it is inconvenient, and Article 36(2) of the Korean Personal Information Protection Act requires deletion without delay and has no equivalent of putting data beyond use. So what follows is a shortfall stated plainly, not a right being asserted: for as long as the lock stands, that copy is read for nothing but a disaster restore and a restore check, it is never used to look anybody up, and if a restore ever happens the Operator re-applies, before the service comes back, every deletion it still holds — those asked for by message, which it keeps outside the database. A deletion you made yourself inside the Service after that copy was taken has its only record inside the same database, so it cannot survive the copy; the Operator posts a notice in the Service when a restore has happened so that you can make it again. That is stated rather than promised away. The outside date is ninety-one days from the day the copy was written. The lock is there to stop somebody who reaches the storage account from wiping the backups; the Operator has weighed that against the delay and left the lock in place, and the delay described here is what that choice costs you. (c) Safety copies taken by hand immediately before a database migration: these are full copies, they are kept outside the rotation on purpose so that a failed migration can be undone, and they are deleted thirty (30) days after they are taken. Thirty is the window the purpose asks for: a migration that went wrong shows itself within days, and after that the ordinary rotation is the way back. How many exist at any moment depends on how recently the database was changed; this Policy does not print a count, because a count in a document goes stale the next time a change is made. Backups are used for two things only: restoring the service after a failure, and periodically checking that a backup really does restore. That check runs by restoring into a test database separate from the service, and the restored copy is discarded when the check finishes. In neither case does the Operator read a backup to look up an individual. Audit-log entries (other than the IP-HMAC component, which becomes unlinkable on the next salt rotation) and ban or sanction records are retained only for as long as necessary for security review and dispute resolution and in any event no longer than three (3) years from the date of the entry, unless a specific legal obligation or an unresolved dispute requires longer retention. One case runs the other way: where a restriction is permanent, the record of it is kept for as long as the restriction stands, because the record is the only thing that makes the restriction knowable and contestable. It is deleted when the restriction is lifted. Consent records (your accepted Terms/Privacy versions and the acceptance timestamp) are retained for as long as your Account exists, and after deletion for the limited period during which the Operator may need to evidence that consent was given, after which they are deleted. Retention for the categories newly stated in Section 4: direct messages, saved posts, lists, hidden words, channel-level consents and reading history are kept while your account exists and go when you delete it. Archive deposits are kept until the Operator has dealt with what was left and no longer needs it. Because a deposit has no account behind it, no fixed period can be attached to it in advance, so the criterion is stated instead: the Operator reviews the Archive at least once every twelve months and deletes everything that is no longer needed at that review. A deposit is also deleted at the depositor's request, and on a request by someone whose personal data is inside it (Terms Section 29). Channel-level block records and their reason notes are deleted when the block is lifted or when the account is deleted. Records of a channel-moderator role and evaluations of a moderator survive the end of the role but go when the account is deleted. Post-move requests are kept for one year after the request is settled. A content report is kept while it is open and for ninety days after it is decided; the name and address a reporter left are deleted the moment the Operator has answered, and at the latest with the report itself. A ban appeal is kept for ninety days after it is answered; the contact address on it is deleted the moment the answer is sent. A notification is kept until you delete it or your Account is deleted, and in any event no more than three years from the day it was written. These periods are not left to memory: a job runs once a day and deletes what has passed them. Before 22 August 2026 the periods were written here and nothing enforced them. How data is destroyed: personal data whose retention period has passed, or whose purpose has ended, is destroyed without delay. Electronic records are deleted by means that leave them unrecoverable, and copies inside backups disappear on the rotation described above. There is at present no item that a Korean statute requires the Operator to keep for longer, so no such item is kept separately and none is listed. That follows from what the Service is: it takes no payment, so none of the record-keeping duties that attach to electronic commerce arise. Should that ever change, this paragraph will name the statute, the items kept under it, and the period. Where an item is kept because a dispute is open, that is not a statutory preservation duty but the legitimate interest in Section 3, and it ends when the dispute does.
11. Your rights, and a legal representative's
Subject to the law that applies in your jurisdiction, you may have the right to: access your personal data; correct inaccurate or incomplete data; request erasure (the "right to be forgotten"); restrict or object to processing; receive a portable copy of your data in a structured, commonly used, machine-readable format; withdraw consent (where processing is based on consent), without affecting the lawfulness of processing carried out before withdrawal; and lodge a complaint with the supervisory authority in your country of residence. You can delete your account yourself, from the Account area of the settings page. Deleting it removes your account details and sign-in link, your direct messages, support tickets, reports and bug reports, ban appeals, reactions and follows, saved posts and lists, hidden words, and your reading history. Posts and comments you already published stay, with the author name replaced by an erased marker and the link to your account cut — removing a whole conversation would take other people's replies down with it. If you want your posts gone too, delete them before you delete the account. If you did not, that is not the end of it: write to the address in Section 2 naming the posts — the address of each, or enough of the text to find it — and the Operator will delete them. This works after the account is gone, because the request identifies the posts rather than the account. Before deleting anything the Operator satisfies itself that the request comes from the person who wrote the posts: a route that took anybody's word would be a way of deleting other people's writing. How that is done is worth stating exactly. Once the account is gone, no link between you and the post is left in the database, so there is nothing to compare you against — the check is therefore against the post itself: whether you know its address, and whether you can describe its content as specifically as the person who wrote it. Writing the addresses down before you delete the account is the surest way. Where the match does not hold, the Operator tells you what it could not verify and does not delete. Be aware of what that does to a thread: deleting a post deletes the comments underneath it as well, and every Member who commented is notified that the post they wrote under is gone. A Guest who commented has no account to notify, so they are not told. That is why account deletion does not do it for you — it would take other people's writing down with it, without their asking. To exercise any of these rights, contact the Operator through any of the contact options described in this Policy — the email address in the Contact section, the in-Service Support channel, or the in-Service Bug & Operations Reports channel. The Operator will respond within the time limits required by applicable data-protection law and, in any event, without undue delay — under the EU/EEA GDPR this is normally within one month of receipt of the request, extendable where the law permits for complex or numerous requests — and at no charge for routine requests; manifestly unfounded or excessive requests may be refused or charged a reasonable fee in accordance with applicable law. Two different things are described here and they are not the same right. The first is the portable copy: ask for it and you receive, in a machine-readable form, what is tied to your account. It is generated automatically, and what it leaves out is this: messages the other person wrote in a conversation; a moderator's reason note on a channel-level block; sign-in and session tokens; the audit log; the record of a channel-moderator role you held and the evaluations other Members left about you in it; requests to move a post; account-level write timeouts; and the Operator's own working marks on your material — whether a post is hidden and why, whether an automatic filter flagged it, whether it was pinned or featured, and the counters the Service uses to sort things. The first two were written by someone else, the tokens are themselves the means of opening your account, and the working marks are the Operator's record of what it did, which access reaches (below) even though the automatic bundle does not carry it. This list is not kept by hand: a test compares it against the database column by column and fails when a column is neither in the bundle nor named here. The rest are omissions of the automatic bundle, not limits on your rights — ask for access, described next, and they are gone through by hand and given to you. The second is access. Access is not the automatic bundle and is not limited by what the bundle happens to contain. Ask for access and the Operator goes through what is held about you by hand, including the two items above, and gives you everything except the parts whose disclosure would harm someone else's rights — and it decides that item by item, not as a class. Where a part is withheld you are told which part and why, and how to contest that. Under the Republic of Korea Personal Information Protection Act this is handled within ten days of the request; the grounds on which access may be restricted are only those listed in Article 35(4) of that Act, and if the Operator restricts or refuses access it tells you the ground and how to contest it at the same time. You may contest it through the email address in Section 2 or the in-Service Bug & Operations Reports channel, and the Operator looks at it again and tells you the outcome. You may also apply to the Personal Information Dispute Mediation Committee (privacy.go.kr, 1833-6972) or the Personal Information Infringement Report Centre (privacy.kisa.or.kr, 118). Objecting, separately. Where the Operator relies on legitimate interests — the categories are named in Section 3 — you have a distinct right to object at any time on grounds relating to your particular situation, and this is set out on its own here because it is easy to lose in a list. To object, write to the contact in Section 2 and say what you object to and why. The Operator will either stop that processing or explain the compelling legitimate grounds for continuing, and will answer within one month. Where the Republic of Korea Personal Information Protection Act applies, the same objection is a demand to suspend processing under Article 37 of that Act: the Operator suspends without delay, tells you the outcome within ten days of receiving the demand, and may decline only on one of the four grounds listed in Article 37(2) — telling you the ground and how to contest it. Objecting costs you nothing and carries no disadvantage. A legal representative. The legal representative of a child under the age of fourteen may exercise the rights above on that child's behalf under Article 38(2) of the Republic of Korea Personal Information Protection Act. Write to the address in Section 2 with the child's display name and something that shows you are the legal representative; once the Operator has established that, the request is handled within the same time limits as any other.
12. Automated decision-making
The Service applies automated controls for anti-spam and abuse-prevention purposes: rate limiting per daily IP HMAC and per Account, request deduplication, automated content filtering for the categories listed in Section 6 of the Terms of Use (the "severe-content filter"), the strictness of which the Operator configures separately for each board, and a Cloudflare Turnstile human-verification challenge for write actions. Depending on the board's configured strictness, the severe-content filter may refuse a submission, hide it pending human review by the Operator, or flag it for review while leaving it visible; in addition, where behaviour is judged abusive — for example the same text posted repeatedly in a short period — writing from that connection point is blocked until UTC midnight that day, without human review, which blocks every write during that period rather than merely one attempt, and does not block reading. Who this reaches: the block is keyed to that day's connection point, not to an account, so anyone else writing from the same line or the same network is blocked for the rest of that day as well, whether or not they did anything. If that has happened to you, say so through the form on the block notice page and the Operator will look at it. The Operator's own view is that these controls do not produce legal effects on you and do not significantly affect you in any other way comparable to a legal effect. That is the Operator's view and not a finding — whether an automatic block that stops every write from a shared line for the rest of the day is a significant effect is for a supervisory authority to decide, not for the party that set the block. The rights below are given in full either way, so nothing turns on the question for you. The filter also has to be described honestly: it reads what you typed, exactly as you typed it, so if there is health, political or comparable material in your words it passes through the filter with the rest. That reading has one purpose — deciding whether the text falls into one of the categories in Section 6 of the Terms — and nothing is extracted, tagged or kept separately afterwards. If you believe an automated action against you was incorrect, you may request human review by the Operator through the in-Service Bug & Operations Reports channel. For those decisions made without human review there are three separate things you may ask for, and you may ask for any of them: you may object to the decision; you may ask for an explanation of the criteria used and of how the decision was reached; and you may set out your own account of the circumstances, with any further information about yourself, and ask the Operator to review whether that changes the outcome. The Operator tells you what it decided on that review and why. How: when access is blocked, the notice page states the block and how much longer it has to run, and carries a form for telling the Operator. That form takes one submission per restriction per person; if you are not signed in and somebody else on the same connection has already used it for the same block, use the email address in Section 2 instead. While signed in you can also use the in-Service Bug & Operations Reports channel, or the email address in Section 2 of this Policy. The Operator answers within thirty days of receipt and a person looks at the decision again. That is a different deadline from the one month in Section 11 and the ten days in Section 9 because a different provision sets each; where more than one reaches you, the Operator works to the shorter. An automatic block lifts at UTC midnight on its own, so in most cases it will be gone before the review finishes. The review still happens, and it is not a formality: it decides whether the block was right, whether the same thing will happen to you again, and what the Operator's own record says about it. That thirty-day limit is the one set by Article 44-3(5) of the Enforcement Decree of the Republic of Korea Personal Information Protection Act; it may be extended twice, by up to thirty days each time, and only after telling you why. Objecting or asking for an explanation carries no disadvantage of any kind. This right applies regardless of the limit on the number of appeals set out in Section 10 of the Terms.
13. No sale or share for advertising purposes
The Operator does not sell, rent, or hand over personal data to third parties for money or other valuable consideration, and does not provide personal data for cross-context behavioural advertising. The Service carries no advertising and no advertising identifiers. The Operator does not collect or process sensitive personal data to infer characteristics, and does not use personal data for profiling that produces legal effects or similarly significant effects. What the Service stores is listed in Section 4 and who receives it is listed in Section 8. The sources are you and your sign-in provider, and the purposes are operating, securing, and providing the Service and preventing abuse. The rights set out in Section 11 — access, correction, deletion, restriction of processing, and a portable copy — are offered to every User on the same terms, wherever they live. One thing sits outside that: material placed in the Archive (Terms Section 29) is not tied to an account, so it is not part of the copy of your account data, and requests about it go to the contact point below. The Operator has limited means of establishing that a requester is the person who deposited the material, and cannot act where that is not established. The Operator does not treat you differently according to whether you exercise them.
14. Minors
The Service is not directed to children, and the Operator does not knowingly collect personal data from anyone below the minimum age of sixteen (16) set out in the Terms of Use. That sixteen-year threshold is an operator policy aligned with the default age of consent for information-society services under the EU/EEA GDPR; it is higher than the fourteen-year floor permitted for personal-data processing under the Republic of Korea Personal Information Protection Act, and where your local law sets a different age of digital consent the higher of that age or sixteen applies. The Operator does not seek verifiable parental consent to enrol younger children, because the Service is not directed to them. If you believe that a person below the applicable minimum age has provided personal data to the Service, please contact the Operator at [email protected] or through the in-Service Bug & Operations Reports channel and the data will be deleted without undue delay.
15. Security
The Operator implements reasonable technical and organisational measures to protect personal data, including: TLS termination at the network edge with no public origin port; IP-derived anti-spam values computed under a daily-rotating random salt that is held only in volatile memory and irrecoverably discarded at the end of each UTC day (see Section 6), so that a database compromise alone cannot recover prior-day IP-based identifiers; in the rare event that the in-memory salt store is unavailable, a random value created when that server started is used instead; that value also lives only in memory and is never written down, so values produced during such a period likewise cannot be turned back into an IP address from the database alone; least-privilege database access by the application; daily database backups, kept on the same physical disk as the origin server and rotated on the schedule set out in Section 10, with an off-site copy taken once a day; audit logging of all administrative actions; and server-side operational logs (performance and error logs) that record response times and software errors — these logs contain no personal data (no IP addresses, no user content) and are stored only on the origin server with rotation at 10 MB / 5 MB respectively. Raw IP addresses are not stored, so a database compromise cannot expose IP addresses of Users. No internet-facing system can be guaranteed perfectly secure. In the event of a personal-data breach affecting your data, the Operator will notify affected Users and any required supervisory authorities within the time limits applicable in the relevant jurisdiction.
16. Changes to this Policy
This Privacy Policy may be updated at any time. The current version is identified by the version label and the "last updated" date displayed at the top of this page. When the version changes, you will be required to re-accept the updated Policy before using any feature that requires acceptance.
17. Multiplayer connection (signaling) data
When you use multiplayer, the Operator's signaling server processes connection events in order to establish the peer-to-peer connection between participants. The data processed is the source IP address and port and the assigned peer IDs. The purpose is limited to establishing the peer connection you request and to preventing abuse. The lawful basis is not consent but legitimate interests (GDPR Art. 6(1)(f)) and service provision under Korea's Personal Information Protection Act (PIPA). This data is minimized, held only transiently in memory for as long as needed for connection setup and abuse prevention and not written to durable logs; any data derived for abuse prevention is purged on a daily rotation at UTC midnight. The Operator does not use it for profiling or advertising. After the connection is established, gameplay and chat travel directly between participants and do not pass through the Operator, so the Operator does not receive or store them.
18. Contact
Privacy questions and data-subject requests can be sent by email to [email protected], or through the in-Service Support channel, or through the in-Service Bug & Operations Reports channel. The in-Service forms are the preferred channels because they let your request be tracked and handled fairly; the email address above is the direct alternative and is the contact point of the Operator (the data controller) for the purposes of applicable data-protection law. The Operator provides the Service from the Republic of Korea (대한민국). You also have the right to lodge a complaint with the data-protection supervisory authority of your country of residence (for example, in the Republic of Korea, the Personal Information Protection Commission; in the EU/EEA, your national supervisory authority; in the United Kingdom, the Information Commissioner's Office).