Privacy Policy
CLOVERA PRIVACY POLICY
Last updated: October 21, 2026
Contact: kitteniversestudios@gmail.com
1. Scope
This Privacy Policy explains how Clovera, a service operated by Kitteniverse Studios, collects, uses, stores, shares, and protects personal data in connection with the service.
2. Data We May Collect
Clovera may collect:
(a) account data: a username, a password (stored only as a hash), a language preference, and optional profile details such as a display name, pronouns, a short biography, a custom status, an accent colour, a profile photo, and a banner. A user who wants the birthday marker shown on their profile may also give the day and month of their birthday; the year is never asked for and is never stored, so Clovera holds no date of birth and cannot derive an age from what it holds. Registration requires only a username and a password. Clovera does not ask for, and does not collect, an email address or a telephone number; an internal, non-deliverable placeholder address is generated for the account record so that the account table has a unique identifier;
(b) technical data: the IP address of each connection, which the server sees while a request is being handled and which is afterwards retained only as a one-way keyed digest (taken, for an IPv6 connection, of the /64 network the address belongs to rather than of the single address, since that network is what identifies the subscriber), and only in the records listed in Section 12 and, for a few hours at most and only in the server's working memory, in the Kitguard counts that Section also describes; and the browser's User-Agent string. Clovera does not derive or store the geographic location of users from their IP addresses, and does not record the operator or the type of the network a user connects from. It does place a random identifier in a signed-in user's browser so that the browser can be recognised again, for the security and enforcement purposes set out in Section 12, and keeps a digest of it;
(c) usage data: login times, failed login attempts, interactions, reports, blocks, community participation, and feature usage;
(d) content data: messages, posts, comments, blog articles, attachments, profile text, and other user-submitted content, including a message written now and scheduled to be sent later, and what a user writes to the KittenAI assistant;
(e) safety and moderation data: report records, enforcement history, detection signals, and abuse-prevention logs;
(f) call and voice-channel data: that a call took place, between which two accounts, whether it was answered, and when it began and ended; and, while a user is in a voice channel of a community, which channel they are in and whether they are muted, deafened, or sharing a screen. What is spoken or shown during a call is not recorded, as Section 8 explains.
3. How Data Is Used
Clovera may use personal data to:
(a) create and manage accounts;
(b) provide messaging, community, feed, moderation, and support functions;
(c) protect users and the service from spam, fraud, abuse, illegal activity, and security threats;
(d) enforce platform rules and legal obligations;
(e) improve reliability, performance, and user experience;
(f) communicate service notices, policy updates, and support responses. Because Clovera holds no email address, these are delivered inside the service — as on-screen notices, as the acceptance screen shown when the policies are revised, and, where a user has enabled them, as push notifications. Clovera cannot contact users outside the service unless they write to the contact address first.
4. Legal Bases
For users in the European Economic Area, United Kingdom, or similar jurisdictions, Clovera may process personal data under one or more lawful bases, including:
(a) performance of a contract;
(b) legitimate interests, such as security, fraud prevention, moderation, and service improvement;
(c) consent, where required;
(d) compliance with legal obligations.
5. Data Sharing
Clovera does not sell personal data. Clovera does not use analytics, advertising, or audience-measurement services. Data may be shared:
(a) with the providers listed in Section 16, each of which receives only the data described there and acts on Clovera's behalf or under its own terms as stated in that Section;
(b) when necessary to investigate abuse, enforce rules, or respond to lawful requests;
(c) in connection with legal claims, safety incidents, or protection of rights;
(d) if the service is reorganized, sold, or transferred, subject to applicable law.
6. International Transfers
Because Clovera is an international online service, data may be processed in countries other than the user's own. Every provider named in Section 16 may process data on servers outside the user's country, including outside Türkiye and the European Economic Area. This applies to content submitted to KittenAI features (Section 15), to the IP address and challenge token sent to a bot-protection provider, and to push notification delivery. Where required by law, Clovera relies on the transfer mechanisms provided under each provider's terms, such as an adequacy decision (including the EU–U.S. Data Privacy Framework where applicable) or standard contractual clauses.
7. Retention
Clovera keeps personal data only for as long as reasonably necessary for the purposes described in this Policy, including operation of the service, safety, dispute resolution, legal compliance, and enforcement. Different categories of data may be kept for different periods depending on risk and legal need.
Account content, login records, and failed login records are retained for as long as the purposes above require and are not deleted on a fixed schedule; login and session records tied to an account are removed when that account is deleted under Section 17. Failed login records are not linked to any account, because a failed attempt may not correspond to a real user; they consist of an IP digest, the username that was attempted, the reason for the failure, and the User-Agent string.
When a user deletes one of their own messages, the message is marked as deleted and stops being shown to the participants, but the stored copy remains in Clovera's database rather than being erased immediately — encrypted in the case of a direct message, in plain text in the case of a group or community message, as Section 8 explains. This is deliberate: a message deleted seconds after it was sent is frequently the subject of an abuse report, and destroying it on request would make such reports impossible to assess. Deletion in the sense of destruction is described in Section 17.
Abuse reports filed by users carry a category chosen by the reporter (for example fraud, threats, or content involving minors) and a free-text explanation. When a report is reviewed, the outcome of the review is recorded with it. Once a report has been settled — upheld or dismissed — for 180 days, its free-text explanation is erased; the category, outcome, and dates are kept so that the amount of unlawful use of the service can continue to be measured. For the same measurement, Clovera also keeps daily counters of automated moderation events; these counters consist of a date, an event name, and a number, and contain no user identifier, content, or address. Private messages are not read or scanned to produce any of these figures.
8. Security
Clovera uses reasonable technical and organizational measures to help protect personal data. Direct messages between two people are encrypted at the application layer while stored on Clovera's servers (encryption at rest using ChaCha20-Poly1305), as are post bodies, post comments, blog articles and their comments, and the cached translations of direct messages. Passwords are never stored in plaintext — they are protected using a strong hashing algorithm.
Group messages, community channel messages, forum threads and forum replies, and the questions and options of polls are not encrypted at rest. They are stored in plain text in Clovera's database. This is a deliberate choice made on 14 September 2026, and it is a change from the previous revision, which encrypted them: a message written to a group, and above all a message written in a community to people the sender may never have met, has to be capable of being examined when it is reported, when a community is being investigated for organising abuse, and when a lawful order requires it — without that examination depending on a decryption step that hides how readable this content already is to the operator of the service. A user should therefore treat anything written in a group chat, a community channel, a forum, or a poll as content the operator of Clovera can read, and Clovera prefers to say so plainly rather than describe as encrypted something it can decrypt at will.
Files are not encrypted at rest, whatever they are attached to. A photograph, a video, a recorded voice message or a document sent in a direct message, a group chat or a community channel, and a profile photo or a banner, are stored on Clovera's servers in the form in which they arrived; only the message text around them is encrypted. Who may fetch such a file is controlled — a file attached to something that is not public is served only to an account already entitled to see it, as Section 14 describes — but the operator of the service can open it. The same is true of several other things a user writes, which are stored in plain text: the title of a blog article, a message scheduled to be sent later while it waits to be sent, what a user writes to the KittenAI assistant and what it answers, profile text, and the names of communities, channels, and groups.
Calls, voice channels, and screen sharing are not stored at all. A one-to-one call started from a direct message carries sound only; a voice channel in a community carries sound and, where a member shares a screen, the picture of that screen or window and its sound where the sharer includes it. None of this is peer-to-peer, and none of it passes through a third party: each participant's stream travels over an encrypted connection to Clovera's own server, which forwards it to the other participants from memory and keeps no copy. Nothing is recorded, nothing is written to disk, and Clovera transmits no sound and no picture to Anthropic or to any other provider; no automated review is applied to a call. The set-up messages the two browsers exchange to start a call, which carry their network addresses, are held on the server only while the call is being set up and are deleted the moment it ends or goes unanswered. Live captions, which a voice channel can switch on, are the one place where what is said is written down, and Section 15(b-ter) describes how. What remains afterwards is what Section 2(f) describes. A user should nevertheless understand that the sound of a call passes through Clovera's server in a form that server can read, which is what makes it different from an end-to-end encrypted call.
The encryption applied to direct messages is applied by Clovera's servers and is not end-to-end encryption either: Clovera holds the key, and content is decrypted on the server when it is delivered to authorized participants and when a participant in the conversation uses a KittenAI feature on it, as described in Section 15; no automated review reads a direct message. No system is perfectly secure, and Clovera cannot guarantee absolute security.
If a breach of security leads to the destruction, loss, alteration, or unauthorised disclosure of or access to personal data, whether by accident or otherwise, Clovera assesses it as soon as it becomes aware of it. Where the law requires notification, Clovera notifies the competent supervisory authority — in Türkiye the Personal Data Protection Board, within 72 hours of becoming aware of the breach, and where the GDPR applies the competent authority within the same period — and, where the breach is likely to result in a high risk to the people affected, tells them as well.
How that notice would reach a user follows from Section 2(a): because Clovera holds no email address and no telephone number for any account, it cannot be sent out of band. A notice to users is therefore given inside the service and on this site — an on-screen notice to every account, and a push notification where the user has enabled them — and describes what happened, what data was involved, what Clovera has done about it, and what the user can do. A person who has stopped using the service, or whose account has been erased, cannot be reached by Clovera at all. That is a consequence of collecting no contact details, and it is stated here rather than left to be discovered at the time.
9. User Rights
Where applicable, users may have rights to access, correct, delete, restrict, object to certain processing, or request portability of their personal data. Users may also withdraw consent where processing is based on consent. Requests may be sent to kitteniversestudios@gmail.com. Clovera may need to verify identity before completing certain requests; because Clovera holds no email address or other contact detail for any account, identity is verified through the account itself, for example by asking the user to post or send a value from the account in question.
Some rights can be exercised directly in the service without making a request: the account and its data can be erased from settings as described in Section 17, profile details and the username can be edited in settings, individual messages and posts can be deleted by their author, active sessions on other devices can be revoked, and Live Translation can be turned off.
10. Children's Data
Clovera does not knowingly allow underage use where prohibited by law and does not knowingly process children's data in violation of applicable law. The registration form asks for a date of birth. It is used within that request to check that the person meets the minimum age stated in the Terms of Service and is then discarded: it is not written to the account record, to any log or to any other store, so Clovera holds no date of birth for any account and cannot later derive a user's age. The day and month of a birthday may be given separately and voluntarily for the marker shown on a profile; the year is never collected there. A browser whose date of birth fell below the minimum age is refused registration for twenty-four hours, by a value held in that browser's own session cookie and nowhere else. Beyond this check the minimum age is relied upon as a representation by the user. If Clovera becomes aware of unlawful underage use, it may remove the account and related data as appropriate.
11. Cookies and Similar Technologies
Clovera sets the following in a user's browser:
(a) a session cookie, which keeps a signed-in user signed in and is necessary for the service to function;
(b) a browser identifier: a random value placed when a user signs in or registers in that browser, described in Section 12;
(c) where the user selects "Keep me signed in on this network", a device cookie for that feature, described in Section 13;
(d) preference values, such as the chosen language and theme;
(e) after a visitor has passed a Kitguard check, a pass cookie for that check, described in Section 12, which expires six hours after it is set.
None of these is used to recognise a browser for any purpose other than the one stated. The browser identifier in (b) exists so that Clovera can tell that two sign-ins came from the same browser; Section 12 sets out what that is used for and what it is not used for. Clovera reads nothing about the device itself in order to recognise it: no fingerprint of the browser, the screen, the installed fonts or the hardware is taken.
Clovera does not use advertising, audience-measurement, or cross-site tracking cookies of its own. Where bot protection is enabled, the bot-protection provider named in Section 16 loads its own script on the login and registration pages, and on the Kitguard check page described in Section 12 when a visitor is asked to pass it, and may set its own cookies or browser storage for the purpose of distinguishing automated traffic; Clovera does not read those values and does not use them for any purpose of its own. A separate cookie notice may be provided where legally required.
12. Login Records, the Browser Identifier, Kitguard, and What Is Kept From an IP Address
Each time a user successfully logs in to Clovera or registers, a record of that login is written. It consists of the user account identifier, the time of the login, the browser's User-Agent string, and a digest of the browser identifier described below, and nothing else. In particular it contains nothing derived from the IP address of the connection: no address, no digest of one, no digest of the surrounding network range, no network operator, and no network category. Clovera formerly recorded an address digest and that network context against every login and no longer does. The reason is that behind proxies and mobile carriers the address reaching the server was frequently not the user's own, so the record linked together accounts that had nothing to do with each other.
The browser identifier. When a user signs in or registers in a browser that does not already carry one, and when a signed-in user's browser is found without one, Clovera places a random value in a cookie in that browser. The value is generated by Clovera, says nothing about the device or the person using it, and expires five years after it is set. It is not removed when the user signs out, because its purpose is to recognise the browser across the accounts used in it. Clovera stores only a one-way digest (SHA-256) of it: on each login record, and in a list held against each account of the browsers that account has been used from, with the time each was first and last seen. A user who clears the site's cookies, or who uses another browser or a private window, is given a new identifier, and nothing connects the new one to the old.
The browser identifier is used for two things only. First, Clovera's administrators can see which accounts have signed in from the same browser. This is how an account opened to evade a ban, several accounts run by one person to manipulate votes, rankings or reports or to harass someone, or a sign-in to an account from a browser that account has never used before, can be noticed. The comparison is shown only to administrators, as a list of the accounts that share a browser. People who share a computer appear in it too, so a shared browser is treated as a reason to look more closely and never as proof on its own: no account is restricted, suspended or banned automatically because it shares a browser with another, and any decision is taken by a person under the Terms of Service. Second, when an administrator terminates an account, the digests of the browsers that account was used from, together with the digests of any persistent-session tokens described in Section 13, are recorded as banned browsers, and a request from a browser presenting one of them is refused. That record holds only the digest and the time it was made, and may outlive the account.
The browser identifier is not used for advertising or analytics, is not used to follow a user across other websites, and is not disclosed to any third party. The legal basis for this processing is Clovera's legitimate interest in keeping accounts secure and in making its rules, and the bans it imposes under them, effective (Article 6(1)(f) GDPR where applicable); users have the right to object to it under Article 21 GDPR. A user who does not want the identifier can remove it at any time by clearing the site's cookies, with the consequence that their next sign-in is treated as coming from a new browser.
The IP address of a connection is still seen by Clovera's servers while a request is being handled, and is used at that moment to apply rate limits, to check the address against a ban already in force, where bot protection is enabled to verify a challenge with the provider named in Section 16, and to keep the Kitguard counts described at the end of this Section. Once the request has been handled, the address is retained only as a one-way keyed cryptographic digest, and only in the seven records below. The raw address is not stored in any of them.
(a) Registration. A digest of the address used at registration is stored on the account record, so that a single address cannot be used to create an unlimited number of accounts.
(b) Sessions. Every active session record stores a digest of the address and the User-Agent string of the device that created it. This is what allows a user to see their active sessions in settings and sign other devices out. It applies to every session, whether or not the user has selected the optional feature described in Section 13. Two further uses are made of this digest: the one in (e) below, and the one Section 15(d) describes, which is also made of the registration digest.
(c) Failed logins. A failed login attempt is recorded with a digest of the address, the username that was attempted, the reason for the failure, and the User-Agent string. A recovery key offered and refused is recorded in the same way, with the reason recorded as a bad recovery key. These records exist to detect password-guessing and account-takeover attempts. They are not linked to any account, because the username attempted may not belong to an existing user.
(d) Persistent sessions, and enforcement derived from them. Where a user has selected "Keep me signed in on this network", a digest of the address is stored with the device token, as Section 13 describes. Where an account is later banned, the digests stored with its persistent-session tokens are recorded as banned addresses, so that the same address can be refused, and that ban record may outlive the account.
(e) Account recovery requests. Clovera holds no email address, so a user who has lost their password and their recovery keys may instead ask for the reset to be approved from a device that is still signed in to the account. That request is stored with the account it concerns, a random token, an expiry, the User-Agent string of the browser that made it, and a digest of the address it was made from. The digest is used for one thing: it is compared with the digests held on that account's own session records, so that the person deciding on the request, on their other device, is shown whether it came from an address the account has signed in from before or from one it has not. Both the User-Agent string and that answer are shown to them, because a request to reset a password is exactly the kind of thing a person needs enough information to refuse. The request is deleted with the account.
(f) Rate-limit counters. An action that is rate-limited — signing in, registering, asking for a recovery, and some content actions — is counted against a row holding the digest of the address, the name of the action, a count, and the times at which the window opened and was last touched. The count returns to zero when the window passes. The row carries no account identifier, holds nothing about what was done beyond the name of the action, and is not deleted on a fixed schedule.
(g) Kitguard measures in force. Where Kitguard has stopped an address, a browser or an account, or asked it to wait, or the service has temporarily blocked an address, as described at the end of this Section, the measure is also written to the database so that a restart does not lift it. The record holds the digest of the address, or the value identifying the browser described in (iii) of that part, or the account identifier, together with the reference code, the kind of behaviour behind the measure, the times it began and ends, and how many times it has been repeated. Scores and everything else Kitguard counts are not written. The record is deleted when the measure ends, and none lasts longer than a day.
The digest is produced with a keyed one-way function (HMAC-SHA-256) using a secret key held only by Clovera. The key matters: the space of possible IPv4 addresses is small enough that an unkeyed digest of an address could be reversed by exhaustive search, and keying removes that possibility for anyone who does not hold the key.
These records are maintained for security purposes, including detection of unauthorized access, account recovery support, abuse investigation, and enforcement of platform rules. They are not used for advertising, behavioral profiling, or cross-service tracking. The legal basis for this processing is Clovera's legitimate interest in protecting the security of user accounts and the integrity of the platform (Article 6(1)(f) GDPR where applicable).
Login records, the list of browsers held against an account, session records, persistent-session tokens, recovery requests and the registration digest are removed when the account is deleted under Section 17. Failed login records and rate-limit counters carry no account identifier and are therefore retained independently of any account. A Kitguard measure held against an account is deleted with the account; one held against an address or a browser carries no account identifier and ends by itself within a day. A ban recorded against an address digest or a browser digest may be kept after an erasure, as Section 17 explains.
Kitguard. Kitguard is the automated check that stops a connection or an account whose behaviour strongly suggests automated abuse, and asks it to pass a verification before it continues. It works as follows.
(i) What it counts. Kitguard keeps a score for the digest of the address a request comes from, for a signed-in user's account identifier, and, once a browser has passed the verification, for that browser as described in (iii). The score rises when one of these things happens: requests keep arriving faster than the per-second limit set for an address or for an account, so that at least thirty of them are refused within a minute — images, avatars and the site's own files count for very little toward that limit, and requests refused only because many people share an address are not counted against any one of them; an action that publishes something or reaches other people, such as sending a message, posting, commenting, sending a friend request or filing a report, runs into its rate limit — typing indicators, edits, live updates and translations are not counted; a sign-in, registration or password recovery is refused because too many attempts have already failed or been made, or a bot-protection check or the arithmetic question on the login or registration page is failed — a single wrong password is not counted; an attempt is made to register beyond the number of accounts allowed from one address; a request is made for a path that only vulnerability scanners ask for, more than thirty requests within a minute are made for pages that do not exist — images and other files do not count toward that — or a burst of requests that change something is made for such pages, or numbered pages are fetched one after another in the way Clovera treats as a sweep for identifiers; a request follows the hidden link that every page carries, which no person can see, select or reach with the keyboard and which the site's robots file tells crawlers not to follow, and which on its own leads to a stop whatever threshold is set; the path of a request, its query string — apart from search boxes and other fields into which people type text — or the browser's User-Agent string contains one of a fixed list of well-known attack patterns, such as attempts at database injection, script injection, reading files outside the site, template or command injection, or sending the visitor on to another site, and only the fact that such a pattern was present is noted; a request uses one of the request methods no browser sends; someone who is not an administrator requests the administration pages; a request is larger than the service accepts; more than twelve different pages are refused to the same address within a minute because the person asking has no access to them; or something an account in its first period after registration is submitting, or a username chosen at registration, is blocked by the automated content review described in Section 15(c) — content of an established account is not counted, so a mistake by that review does not turn into a stop. The serious-crime screen in Section 15(e) is never counted. Each event carries a fixed weight, and the score halves every fifteen minutes. Apart from requests that only machines make, an event of the same kind is counted at most once every five to thirty seconds, so that a person who keeps running into the same limit is not scored as though they were a flood. Kitguard keeps nothing about the content or the request involved — only that an event of one of these kinds occurred and when. A search engine crawler verified as such, administrators, and the service's own bot accounts are not scored.
(ii) When it stops someone. When the score reaches a threshold the operator sets, which is 100 unless the operator changes it, requests receive the Kitguard page instead of what was asked for until a verification is passed. A visitor who is not signed in is assessed on the score of the address, until their browser has passed the verification once; from then on it is assessed on what that browser itself does, and not on what others do from the same address. A signed-in account is assessed on its own score and, during the period after registration in which an account counts as new — 24 hours unless the operator changes it — also on the part of the address's score that comes from requests arriving too fast or from probing, but not on sign-in failures, limits or blocked content, which on an address shared through a mobile network or a school may well be other people's; once that account's browser has passed the verification, on that browser's own score instead. An established account is not stopped because of anything done from the same address by anyone else. The page names the kind of behaviour that led to the stop and shows a reference code.
(iii) The verification. Where bot protection is enabled, the verification is the hCaptcha challenge described in Section 16(c), and the browser also performs a short calculation that Clovera checks on its server; the calculation reads nothing from the device and produces only a number. Where bot protection is not enabled, or where Clovera's server cannot reach the provider, the visitor is instead asked to hold a button down while the browser performs the same calculation. Passing the verification ends the stop and sets the pass cookie listed in Section 11(e). Where the stop was on the score of an account or of the visitor's own browser, that score returns to zero. Where it was on the score of an address, the address keeps its score, because others — including whatever caused it — may be using it too, and only the browser that passed is let through. The cookie holds only its expiry time and a signature computed from the digest of the address and the User-Agent string, so it is valid only from the same address and the same browser; Clovera keeps no copy of it. While it is valid, Kitguard keeps the separate score for that browser mentioned in (i), identified in memory by a value derived from the same digest and User-Agent string, and does not stop that browser because of the address's score; and while the operator has switched on attack mode, described in (v), that browser is not asked again. It expires six hours after it is set.
(iv) Repetition. A browser holding a pass that is stopped again, while nobody is signed in on it, after passing the verification three times within an hour, and an account or a browser holding a pass that fails the verification six times within ten minutes, is asked to wait before it may try again: ten minutes the first time, doubling on each further occasion within the hour, to at most sixty minutes. The verification also has to be passed within five minutes of the page first being shown, with a few seconds' allowance for an answer already on its way; otherwise the same wait follows, ten minutes the first time and doubling, to at most sixty, if it happens again within the hour, and a new five minutes starts when the wait is over. Where the stop is on an address, that clock is kept for each browser separately, identified in memory by the value described in (iii), so that one person leaving the page open does not make others on the same address wait; where it is on an account or on a browser holding a pass, it is kept for that account or browser. On an address from which someone has passed the verification within the last hour, failed attempts are not counted toward that wait, so that one person's failures do not make others wait. An address that keeps sending requests while it is stopped — 300 requests within five minutes — and from which nobody has passed the verification within the last hour is refused altogether for a limited time, except for requests made from a session that is already signed in, by the temporary address block the service already applies to hostile clients: an hour the first time, longer on repetition, and never more than a day. An address from which someone has passed within the last hour is never blocked in this way, because it is evidently shared with people. That block is kept in the record described in (g) above until it ends, and it does not suspend, restrict or otherwise affect any account. Referral to an administrator: a signed-in account that is stopped again, on its own score or on that of the browser it is using, after passing the verification three times within an hour has shown that a person is behind it, yet keeps behaving in the ways listed in (i). Kitguard does not make that account wait. It opens a case for Clovera's administrators instead, in the same review queue as the cases described in Section 15(d), and notifies them. The case holds the account identifier, the number of times the verification was passed within that hour, the kind of behaviour behind the stop and the reference code; it holds no address, no digest of one and nothing about the requests involved. Unlike everything else Kitguard holds, it is written to the database, encrypted, and it is kept, and its contents erased when the account is deleted, in the same way as those cases. Only one such case is open for an account at a time. The case changes nothing about the account, which still has to pass the verification each time it is stopped; whether anything is done is decided by an administrator under the Terms of Service.
(v) Attack mode. The operator can switch on attack mode while the service is under attack. While it is on, every visitor who is not signed in is asked to pass the verification before any page other than the legal documents is shown, and the per-second limits that apply to an address are lowered to a quarter. Signed-in users are not asked to pass it.
(vi) Where it is kept, and for how long. Apart from a referral to an administrator, described in (iv), and the measures in force described in (g) above, everything Kitguard holds — the scores, including the score kept for a browser that holds a pass, the five-minute clocks and the per-second counters — is held in the working memory of the server. None of it is written to the database or to disk, and all of it is lost whenever the service restarts. A stop, a waiting period or a temporary block that is still in force when the service restarts is taken back from the record in (g), without any score, and goes on until it would have ended anyway. An entry is discarded once its score has fallen back to almost nothing; one that nothing has touched for three hours is discarded the next time the service handles a request, unless a stop or a waiting period is still in force; and a per-second counter is discarded in the same way after ten minutes without requests. For the operator of the service, and for no other administrator, Kitguard keeps a list of its most recent decisions: the time, whether someone was stopped, was referred to an administrator, passed the verification, ran out of time, was asked to wait, was released or was blocked, the kind of behaviour behind it, the reference code, and the account identifier where the person was signed in. That list holds no address and no digest of one, and is limited to its last 200 entries and to the last 24 hours. The service's operational log records when the operator releases a stop, with the reference code and the operator's account, and when an address is temporarily blocked, with the reference code but without the address.
(vii) What it does not do. Kitguard does not restrict, suspend or terminate an account, does not remove or hide content, and does not act on anything beyond the requests being made, except that it can refer an account to an administrator as described in (iv). A stop ends when the verification is passed, when an administrator releases it, or by itself an hour after the last request made while it was in force, unless the score is still above the threshold at that point. Kitguard is an automated assessment of how a connection or an account is behaving, and so a form of profiling; the only decisions it can take are to ask for a verification within five minutes, to impose a short wait and to refer an account to a human administrator, none of which produces legal effects concerning anyone or similarly significantly affects them. A person who believes they were stopped wrongly can send the reference code to kitteniversestudios@gmail.com, and the operator of the service can look at the stop and release it.
The legal basis for Kitguard is Clovera's legitimate interest in keeping the service available, and its accounts and communities secure, against automated abuse (Article 6(1)(f) GDPR where applicable). Users have the right to object to it under Article 21 GDPR.
13. Persistent Session ("Keep me signed in on this network")
Clovera offers an optional feature that allows users to remain signed in across browser sessions. When the user selects it at login, Clovera places a random device token in a cookie on that browser and stores, in association with the user account, a digest of that token together with a one-way keyed cryptographic digest of the IP address the user was connecting from. The raw IP address is not stored in this context; only its digest is retained.
The session is restored on a later visit when the browser presents that device cookie and the stored token matches it. Restoration does not in fact depend on the visit coming from the same network: despite the wording of the option, a request from a different address restores the session in the same way. Clovera states this plainly because the wording suggests otherwise, and because it affects how a user should judge the risk of enabling the feature on a device that other people can reach.
The address digest stored with the token is not used to restore the session. It is retained for a second purpose, and this is the only other thing it is used for: if the account is later banned, the digests held with its persistent-session tokens are recorded as banned addresses, so that the same address can be refused when it is used again. The digest is not used for advertising, for tracking across third-party services, or for any purpose beyond those described here.
Users may remove a persistent token at any time, by any of three routes: logging out deletes the token belonging to that browser, "Sign out of all other devices" in settings deletes the tokens belonging to every other browser, and each token can be revoked individually in Settings → Sessions. A token that is not revoked remains valid for as long as the account exists; the accompanying device cookie expires five years after it is set. Tokens are also removed when the account is deleted under Section 17, and when the account is banned.
The legal basis for creating the token and for restoring the session with it is the user's freely given, specific, and informed consent (Article 6(1)(a) GDPR where applicable), expressed by actively selecting the option at login, and withdrawable at any time by any of the three routes above. The legal basis for the second use of the address digest — recording it as a banned address when the account is banned — is Clovera's legitimate interest in making an enforcement decision effective (Article 6(1)(f) GDPR where applicable); that use is not covered by the consent, does not depend on it, and cannot arise for a token that has already been deleted. Users have the right to object to it under Article 21 GDPR.
Users who do not select this option have no persistent token and no digest stored for them under this Section. This is a distinct record from the session IP digest described in Section 12(b), which is created for every session regardless of this choice.
Users should exercise caution and not enable this feature on shared, public, or untrusted networks or devices.
14. Who Can See What a User Writes
Parts of Clovera can be read without an account, and some of them are offered to search engines. This Section says which, because "public" on Clovera means visible to the open internet, not merely visible to other signed-in users.
(a) Readable by anyone and offered to search engines. A post whose author marked it public, a published blog article, and the front page of a community whose owner has listed it publicly can be read by any visitor, with no account and no sign-in. These pages are listed in Clovera's sitemap, so search engines and AI crawlers may fetch and index them. What is shown with them is shown to the same audience: the author's username, display name, profile photo and banner, the reactions and comments on the item, and any file attached to a public post, which is served to visitors without a session for that reason.
(b) Readable by anyone holding the link, but kept out of search indexes. Inside a community whose owner has both listed it publicly and left it open to guests, the text and announcement channels, the forum listing and the forum threads can be read without an account. Those pages are excluded from the sitemap and are served with an instruction not to index them, in the page itself and in the response headers, so that a community can be found through a search engine while the messages written inside it are not put into a search index. Voice, mission, counting and showcase channels are never readable this way, and a channel that its permissions hide from everyone stays hidden from visitors too. The operator of the service can switch indexing of channel or forum pages on; unless it has been switched on, those pages are not offered for indexing.
(c) Guest reading is on unless the owner turns it off. A community that is listed publicly is open to guest reading by default. Its owner can close it in Community settings → Visibility, which keeps the community listed in Discover and closes its contents. The whole of public reading can also be switched off by the operator of the service for the deployment as a whole.
(d) Not readable without an account. Direct messages, group chats, communities that are not listed publicly, channels closed by permission, posts that are not marked public, and the files attached to any of these require an account that was already entitled to see them. Writing is never possible without an account: every action that creates or changes anything requires one.
(e) Who can hear a call. A one-to-one call is heard by the other participant only. A voice channel is heard, and a shared screen is seen, by the members of the community who are in that channel at the time and who are entitled to open it; anyone entitled to open the channel can join it and can see who is already in it. A visitor without an account can never join or hear a voice channel, and a voice channel is never readable from outside the service, as (b) above says. Beyond the participants, the sound and the shared picture pass through Clovera's own server, which forwards them without keeping a copy; Section 8 sets out what that means.
Content that other people, search engines or crawlers have already read, copied, indexed or cached while it was public does not become unreadable when its author later deletes it or makes it private. Clovera removes it from its own service, and ceasing to serve it is what eventually causes search engines to drop it, but Clovera cannot retrieve what a third party has already taken. A user should treat anything marked public as published.
15. KittenAI Features and AI Processing (Anthropic)
Clovera includes built-in artificial intelligence features under the name "KittenAI", including conversation summaries, message translation, Live Translation, reply suggestions, Catch-Up digests, the KittenAI chat assistant, writing assistance, the translation of live captions in voice channels, and automated content moderation. KittenAI is powered by Anthropic's Claude models, accessed through the Claude API operated by Anthropic, PBC. Anthropic acts as a third-party processor for these features.
When a KittenAI feature runs, the relevant content is decrypted on Clovera's servers and transmitted to Anthropic for processing. Depending on the feature, this content may include:
(a) the text of direct messages, group messages, and channel messages, together with the display names of the participants, where a summary, translation, reply suggestion, or Catch-Up digest is produced from a conversation, or where the user attaches one of their own direct or group conversations to the KittenAI chat assistant as context, in which case the last forty messages of it are sent with the sender names;
(b) posts, post comments, blog articles, usernames, profile text, and messages submitted to the KittenAI chat assistant, together with the earlier messages of that assistant conversation, which are sent again as context each time the user writes to it;
(c) images such as profile photos, banners, server icons, and post attachments (for automated image moderation);
(d) the text of a line of live captions in a voice channel, without the name of the person who said it, where someone in that channel reads another language.
When each feature runs:
(a) User-initiated features (summarize, translate, reply suggestion, community idea, Catch-Up, writing assistance, and the KittenAI chat) run only when the user actively requests them.
(b) Live Translation runs only if the user has turned it on in their settings, and can be turned off at any time. It is off by default.
(b-bis) Web search in the KittenAI chat assistant. Where the operator has left it switched on — it is on by default — the assistant can look something up on the web while answering, using Anthropic's web search tool. Where it does, the model forms a search query out of what the user asked and Anthropic runs the search, which may involve a search provider that Anthropic engages, so the substance of a question put to the assistant may reach that search service as well as the model, and the pages the answer was drawn from are listed under the reply and kept with it so that the user can check where it came from. This happens only in the chat assistant, and only in an exchange the user started by writing to it. No other KittenAI feature can search: an automated moderation check, a translation, a summary, a Catch-Up digest and the screen in (e) never search, so nothing a user wrote to somebody else is ever turned into a search query. How Anthropic, and any search provider it engages, handles a query is governed by Anthropic's terms for the Claude API rather than by this Policy. A user who does not want a question searched should not ask it of the assistant; the operator can switch the whole feature off, and where it is off the assistant answers from the model alone.
(b-ter) Live captions in voice channels run only in a voice channel where someone who can configure that channel has switched them on; they are off by default. While they are on, each speaker's own browser writes down what they say, using the speech recognition built into the browser, and only while that speaker's microphone is on. Where the browser can recognise speech on the device itself, it does so; otherwise the browser sends the sound to its vendor's speech service (for Google Chrome, Google) and receives the words back. That service is a feature of the browser, governed by its vendor's terms rather than by this Policy, in the same way as push notification delivery in Section 16; Clovera's own servers never receive or send the sound. Only the resulting line of text reaches Clovera. It is stored encrypted for at most six hours, shown to the people in the channel, and deleted together with everything else the channel has said when captions are switched off for it or when the speaker's account is erased. Where someone in the channel reads another language, the line is sent to Anthropic to be translated for them, without the name of the person who said it; where everyone reads the speaker's language, no KittenAI feature runs at all. A speaker whose browser cannot write speech down is not captioned, and nothing they say is sent anywhere for that purpose.
(c) Automated content moderation runs automatically, without being requested, on the following: feed posts and their comments — including posts that are not public — blog articles, usernames chosen at registration or changed later, profile text (display name, pronouns, custom status, bio, and custom profile sections), profile photos, profile banners, server icons, messages sent by creator bots, the name, description, welcome message, and channel names of a community, and the name of a group chat. It also runs on messages and forum posts in a community's channels where that community has enabled moderation; where a community has not, nothing written in its channels is measured against the platform rules by any automated process, but it remains within the serious-crime screen described in (e), which asks a different and much narrower question and which the owner of a community cannot switch off. Neither this general moderation, nor the serious-crime screen described in (e), nor any other automated review reads a user's own direct messages or group messages, and no setting can make one do so: direct and group messages are sent to Anthropic only where a participant uses one of the features in (a) or (b) on the conversation.
(d) Account, community, and group review (the "KittenMOD sweep"). At intervals, Clovera also looks for accounts used for spam, communities and groups set up to deceive or to organise attacks, and coordinated attacks on people or communities. This review sends to Anthropic only the texts listed in (c) — a community's name, description, welcome message, and channel names; a group chat's name; an account's profile text; and content already covered by (c). Everything else it uses is counted on Clovera's own servers from usage data (Section 2(c)) without any content being read or transmitted: how often an account publishes and sends channel messages; how many distinct people it sent direct messages to who never wrote back, and how many of them blocked it; how many people it added to newly created groups and how many of those blocked it; how many friend requests it sent; how many people blocked or reported it; how many of its items automated moderation has removed; how many members of a community blocked or reported its owner; how many invite links a community created; whether a community's recent messages were removed by automated moderation in large proportion; whether a burst of newly registered accounts joined a community together and had content removed there; and whether an account's registration or sign-in address digest (Section 12) matches an address digest recorded when another account was banned, which Sections 12 and 13 already name as a purpose. No private message or group message is opened for this review, or for any other automated review. The outcome is a case for a human administrator, containing the counts above and the category found, stored encrypted; where a community is judged to be a scam, an impersonation, or a vehicle for attacks, it may in addition be placed on hold (removed from discovery and closed to new members, its existing members unaffected) until the administrator has looked, and that hold is reversible. Automated review never suspends or bans an account, closes a community, or dissolves a group; those decisions are taken by a human administrator, as Section 2 of the DSA Information states.
(e) Serious-crime screen. Clovera runs an automated screen that puts one question to a piece of text: whether it is itself a step in organised or other grave crime. It covers content written in a community — the messages, forum threads, and forum replies in a community's channels — and nothing else. It never reads a direct message or a group message, and no setting, the operator's or anyone else's, extends it to them.
Content written in a community is within the screen wherever it is written. A community's own moderation setting does not reach it: that setting decides only whether the general moderation described in (c) runs in that community, and the owner of a community cannot switch the serious-crime screen off for the place they run. Only the operator of the service can switch it off, and only for the whole service; where it is switched off, nothing in this paragraph takes place.
Where the screen applies to a piece of content, the following applies to it, and this paragraph describes it in full.
Purpose and question asked. The screen exists for one purpose: to keep Clovera from being used as an instrument of organised and other grave crime. Each message, thread, or reply is put to KittenAI on its own, with one question — whether it is itself a step in one of the following: running a criminal organisation, including recruitment, tasking, the division of proceeds, protection rackets and extortion; trafficking or smuggling people, forced labour, or forced prostitution; terrorism, including recruitment, financing, and attack planning; dealing in drugs, firearms, or explosives, including instructions for making weapons or explosives; the sexual abuse of children, including soliciting, arranging, or sharing such material; arranging violence for another party, including contract killing, kidnapping, and a credible and specific plan to kill or seriously injure a named person; and laundering money, trading stolen payment or identity data, or producing counterfeit money or documents.
What the screen is not. It is not general moderation and cannot be used as such. Insults, threats made in anger, swearing, hate, harassment, bullying, sexual talk between adults, jokes, boasting, roleplay, fiction, personal drug use, and discussion of crime, politics, courts, or police as a subject are outside it and are not flagged by it, however unpleasant they may be. Whether what is written in a community is measured against the platform rules at all is decided by that community's moderation setting and by (c), not here. Nothing the screen reads is used to build a profile of a user, to rank a user, to target anything at a user, or for any purpose other than the one stated above.
What is transmitted. Only the text of the single item is sent to Anthropic, with no username, no display name, no identifier, and nothing else written around it. A file attached to it is never opened, transmitted, or examined by the screen, which reads written text and nothing else. A message that has been deleted is not read at all. A message that carries a file has whatever text accompanies it read in the ordinary way, and the file itself is left alone.
What is kept. Where the screen answers that an item is not within those categories — which is the answer in the ordinary case — nothing whatever is recorded about it and no trace of the reading is kept. Where it answers that an item is within them, Clovera opens a case for a human administrator containing the date, the category found, the account that wrote it, the name of the community and channel it was written in, and an excerpt of at most 200 characters of the text, stored encrypted. No one else who took part in the conversation is recorded in the case.
What happens next. The screen cannot delete anything, hide it, block its delivery or publication, restrict an account, place a community on hold, or take any other action. What was written stays where it was written. Nothing the screen finds is counted towards any other automated judgement either: it is left out of the counts that the account, community, and group review in (d) works from, so it cannot reach an account or a community by that route. A human administrator reads the case and decides: either the case is dismissed, and what was written is left untouched, or it is removed and the account recorded for enforcement. Any suspension, ban, or referral to an authority is a human decision taken on the case, never an automated one.
Legal bases (where GDPR or similar law applies): Clovera's legitimate interests in preventing its service from being used for serious crime and in protecting the people who use it (Article 6(1)(f) GDPR), and compliance with legal obligations to act against illegal content and to cooperate with lawful orders (Article 6(1)(c) GDPR). The screen is confined to the categories above, transmits one item at a time without identifiers, retains nothing where no category is found, and can take no action of its own. What is written in a community's channels is written into a shared space that Section 14 and the Terms of Service already describe as readable by the operator and stored in plain text so that it can be examined, and the narrowness of the question asked of it is what keeps this proportionate; it is not treated as correspondence between two people, and a community owner is not given the power to decide that the place they run is not screened for grave crime. The objection right in Section 9 applies to this processing, and the operator remains bound by the confidentiality-of-communications rules of each jurisdiction in which Clovera is offered.
Until 15 October 2026 the operator could also switch this screen on for direct and group messages. That switch has been removed from the service. A case the screen opened over a direct or group message while it was switched on stays with a human administrator until it is decided, in the way described under "What happens next", and nothing further is read to decide it.
Important: content a user sends to other users may be processed by KittenAI if another participant in the conversation uses an AI feature on that conversation (for example, translating, summarizing, or requesting a Catch-Up digest of it), or if the content is subject to automated safety moderation. By participating in conversations on Clovera, users acknowledge that other participants may use these features.
No KittenAI feature is applied to a call or a shared screen, and no automated review is applied to a call, a voice channel, or a shared screen. Clovera never transmits sound or pictures to Anthropic or to any other provider, and does not record or moderate them. The only content KittenAI receives from a voice channel is the written line of a live caption described in (b-ter), and only to translate it.
A conversation with the KittenAI chat assistant is kept on Clovera's servers in plain text so that it can be shown again when the user returns, and so that it can be given back to Anthropic as context for the next question. It stays until the user clears it with the button on that page, or until the account is erased.
Clovera transmits only the content reasonably needed for the requested feature, together with limited context such as the target language. No account identifier is transmitted; the user identifier is used only inside Clovera to apply per-user rate limits. Translation results are cached in encrypted form on Clovera's servers to reduce repeat processing. Content transmitted to Anthropic is processed by Anthropic subject to Anthropic's Commercial Terms of Service and the data processing terms incorporated in them. Under those terms, content submitted through the Claude API is not used to train Anthropic's models. Anthropic keeps it only for the limited period those terms set, which can be longer for content that Anthropic's automated safety systems flag as breaching its usage policy, and such flagged content may be reviewed by Anthropic's trust and safety staff for that purpose alone. Clovera does not permit its processors to use this content for their own advertising purposes.
Legal bases (where GDPR or similar law applies): user-initiated features and Live Translation are processed on the basis of the user's request and consent (Article 6(1)(a) and, where the feature is part of the requested service, Article 6(1)(b) GDPR); automated safety moderation is processed on the basis of Clovera's legitimate interests in keeping the platform safe and lawful (Article 6(1)(f) GDPR) and compliance with legal obligations (Article 6(1)(c) GDPR).
Where Turkish Law No. 6698 (KVKK) applies, the transmission of content to Anthropic constitutes a cross-border transfer of personal data, as does the processing carried out by every other provider named in Section 16. Such transfers are carried out in accordance with Article 9 of the KVKK, which since its amendment permits a transfer on the basis of an adequacy decision, failing that on the basis of one of the appropriate safeguards the Article lists, and only for transfers that are occasional on the basis of one of the exceptions in its final paragraph. Using a KittenAI feature is not itself the explicit consent the KVKK requires: explicit consent under that Law has to be given expressly, on specific information, and freely, and it is sought separately where a transfer rests on it. The KVKK Privacy Notice states which basis is relied on. Users who do not use KittenAI features and have not enabled Live Translation do not have their private message content sent to Anthropic, except where automated safety moderation applies as described above. Full KVKK disclosures, including data subject rights under Article 11 of the KVKK, are provided in the separate KVKK Privacy Notice available in-app at /legal/kvkk-notice (shown in Turkish or English according to the user's language setting).
Users may object to or limit this processing by not using KittenAI features and disabling Live Translation. Questions and objections may be sent to kitteniversestudios@gmail.com, and the account, community, and group review described in (d) is among the processing to which the objection right in Section 9 applies.
16. Third-Party Services That Receive Data
Beyond Anthropic's role in Section 15, the following services receive personal data when Clovera is used. Each is listed with what it receives and why.
(a) Hosting and infrastructure. Clovera's application and database run on a third-party hosting platform. It necessarily handles all data stored or transmitted by the service, in order to run it. Its role is that of a processor acting on Clovera's instructions.
(b) Typefaces (no third party). The typefaces Clovera's pages use are served from Clovera's own server, like every other file of the site. No request for a font goes to Google or to any other third party, so nobody outside Clovera learns from the typography that a Clovera page was loaded. Until 20 October 2026 the pages loaded them from Google's font servers, and Google received the visitor's IP address and User-Agent string on every page view; Section 20 records the change.
(c) Bot protection — Cloudflare Turnstile (Cloudflare, Inc.) and hCaptcha (Intuition Machines, Inc.). Where the operator has enabled bot protection, the login and registration pages load a challenge script from the relevant provider, and Clovera sends that provider the challenge token together with the visitor's IP address in order to verify the result. The IP address is sent in full to the provider for this check, even though Clovera itself stores only a digest of it. The provider may also set its own cookies or browser storage and collect signals about the browser in order to distinguish automated traffic. This applies only to the login and registration pages and to the Kitguard check page described in Section 12, and only while the protection is enabled; the script is not loaded on any other page. Clovera's server may also contact the provider, with a placeholder value and no data about any visitor, to find out whether the provider can be reached. The purpose is to prevent automated account creation, credential-guessing and other automated abuse; where the GDPR applies, the legal basis is Clovera's legitimate interest in the security of the service (Article 6(1)(f) GDPR).
(d) Push notification delivery. If a user enables push notifications, their browser registers with the push service operated by the browser's vendor (for example Google, Mozilla, Apple, or Microsoft, depending on the browser). Clovera stores the resulting subscription endpoint and encryption keys and sends notification messages through that service. The push service therefore learns that a notification was sent to that subscription and the timing of it; the notification content is encrypted in transit to the browser. A notification says what kind of event occurred and, where there is one, the username of the person who caused it — that someone sent a message, mentioned the user, or called them. It never carries the text of a message. Push notifications are off unless the user turns them on, and turning them off removes the subscription.
(e) Browser speech recognition. Where a voice channel has switched on live captions and a speaker's browser cannot recognise speech on the device, the browser sends that speaker's sound to the speech service operated by its vendor (for Google Chrome, Google) to have it written down, as Section 15(b-ter) describes. The sound goes from the browser to that service directly; Clovera's servers neither send nor receive it, and Clovera receives only the resulting text. This happens only in a channel with captions switched on and only while the speaker's microphone is on.
Clovera does not use analytics, advertising, tag-management, or audience-measurement services, and embeds no third-party content other than what is listed above.
17. Account Deletion and Erasure
A user can erase their own account from the account settings, under "Delete account". The erasure runs immediately and cannot be reversed: there is no waiting period during which the account could be restored. Confirming it requires the account password and the account's own username. An account that owns a community with other members in it cannot be erased until that community has been handed to another member or closed, so that a community is not destroyed along with the account that created it; a community whose only member is the account holder is closed with the account.
A user who cannot reach that control may still write to kitteniversestudios@gmail.com from, or while signed in to, the account concerned, and the erasure will be carried out manually by the data controller. Because no email address is held for any account, such a request must include enough information for the controller to be satisfied that it comes from the account holder, as described in Section 9.
However it is carried out, erasure removes the account record, its login records, the list of browsers it was used from, its session records, the persistent-session tokens belonging to it, any recovery request made for it, the account's direct, group, and channel messages, its posts, comments, blog articles, polls, reactions, and uploaded files, its conversation with the KittenAI assistant, the records of the calls it made or received and its presence in voice channels, the recovery keys issued to it, any bots it created together with those bots' own accounts, and the registration IP digest. A message the account deleted earlier is destroyed at this point too, rather than being kept as Section 7 describes.
Three things are not removed. Failed login records survive an erasure, because they carry no account identifier and may not correspond to a real user at all, as Sections 7 and 12(c) explain, and so do the rate-limit counters described in Section 12(f), for the same reason. Content that other users have received may remain visible to them where it forms part of their own conversation history. And records that Clovera must keep to comply with a legal obligation, to defend a legal claim, or to prevent the recurrence of serious abuse — including a ban already in force — may be retained for as long as that purpose requires, with any link to the erased account removed where the record can stand without it.
Erasure is performed so that the erased data cannot be retrieved or reused. Clovera keeps a record that an erasure took place, holding the date, whether it was carried out by the account holder or by the controller, and the number of records and files removed. That record deliberately contains nothing identifying the erased account, since a log naming it would recreate the very data the erasure destroyed.
Individual items can be removed without erasing the account: a user can delete their own messages, posts, comments, and blog articles at any time, and can replace or remove their profile photo and banner. As Section 7 explains, a deleted message stops being shown but its stored copy is not destroyed immediately.
18. Complaints
Users in jurisdictions with data protection rights may have the right to complain to a relevant supervisory authority if they believe their personal data has been handled unlawfully. A user in Türkiye may apply to Clovera first, as Section 13 of the KVKK Privacy Notice describes, and may then complain to the Personal Data Protection Board (Kişisel Verileri Koruma Kurulu). A user in the European Economic Area or the United Kingdom may lodge a complaint with the supervisory authority of their habitual residence, place of work, or the place of the alleged infringement (Article 77 GDPR). Complaining to an authority does not require complaining to Clovera first, and does not affect any other remedy.
19. Changes to This Policy
Clovera may revise this Policy to reflect changes in the service, in the technology used to operate it, or in applicable law. Each revision is identified by the revision date shown at the top of this document.
Where a revision materially changes how personal data is collected, used, or shared, Clovera will bring the change to users' attention before it takes effect for them, will identify the substance of what has changed rather than merely stating that the Policy has been updated, and will ask users to accept the revised Policy before continuing to use the service. Revisions that do not affect the substance of the processing — such as corrections of typographical errors, clarifications of existing wording, or updated contact details — may be published with a new revision date without seeking renewed acceptance. The same applies to a revision that only takes processing away, such as one that removes a use of personal data or shortens how long it is kept; such a revision is still recorded in Section 20, with what it removed.
A material revision does not retroactively change the basis on which personal data was processed before that revision took effect.
20. Record of Revisions
21 October 2026 — Corrections that follow a security review of the service, none of which adds processing. Section 8 now says that the set-up messages exchanged to start a call, which carry the participants' network addresses, are held only while the call is being set up and deleted when it ends; until this revision the service kept them indefinitely, which Section 8 did not say. The service is also corrected to match what Section 8 already said about scheduled messages: the text of a scheduled message is now erased once it has been sent or cancelled, where the service had kept it. Section 2(b) now says that for an IPv6 connection the address digest is taken of the /64 network rather than of the single address. The rule for the automatic take-down of reported posts in Section 7 of the Terms now counts only reporters of real standing, as that Section describes. Because this revision removes retention and adds no processing, it is published under Section 19 without seeking renewed acceptance.
20 October 2026 — Two changes, neither of which adds processing of personal data. The typefaces are now served from Clovera's own server, so Google no longer receives the IP address and User-Agent string of every visitor on every page view; Section 16(b) now says so, and Google remains named in Section 16 only for push notification delivery. The registration form now asks for a date of birth, which is checked against the minimum age in the Terms of Service within the same request and then discarded; Section 10 describes this, and the check keeps nothing but a twenty-four-hour refusal held in the refused browser's own session cookie. Because this revision removes a transfer and adds a check that stores nothing, it is published under Section 19 without seeking renewed acceptance.
16 October 2026 — KittenAI moved from Google's Gemini models to Anthropic's Claude models, used through the Claude API, and Anthropic, PBC replaced Google as the processor named in Section 15 and in the opening of Section 16; Google remains named in Section 16 only for the hosted fonts and for push notification delivery. What KittenAI reads, and when each feature runs, has not changed. Web search in the chat assistant now runs through Anthropic's web search tool instead of Google Search (Section 15(b-bis)), and Section 15 now states what Anthropic's terms say about training, retention and the review of flagged content. Live captions in voice channels are described for the first time (Section 15(b-ter)). They had been offered before this revision while this Policy said that nothing said in a voice channel was transcribed; until this revision a few seconds of a speaker's sound at a time were sent to the AI provider to be written down and translated. Captions are now written down in the speaker's own browser, Clovera receives text only and keeps it encrypted for at most six hours, and a line is sent to Anthropic only to translate it for someone in the channel who reads another language. Sections 8, 15 and 16(e) now say this. Because the processor changes, users are asked to accept this revision.
15 October 2026 — Removed the serious-crime screen for direct and group messages from Section 15(e). Until this revision the operator could switch that screen on, and the text of each direct and group message was then put to KittenAI with one question. The switch has been taken out of the service, together with the in-app notice that went with it, so that no automated review reads a direct message or a group message any more and no setting can make one do so; Sections 8, 15(c), 15(d) and 15(e) now say this without exception. Direct and group messages reach Google only where a participant uses a KittenAI feature on the conversation, as Section 15(a) and (b) describe. The screen continues to cover what is written in a community's channels exactly as before. A case the screen opened over a direct or group message while it was switched on stays with a human administrator until it is decided. Section 19 now also says what this Policy has done since its 13 August 2026 revisions: a revision that only takes processing away is published without seeking renewed acceptance. This revision adds no processing and removes some, so it is published without seeking renewed acceptance.
13 October 2026 — Described Kitguard, in a new part of Section 12, and the pass cookie it sets, in Section 11(e). Kitguard keeps, in the server's working memory only, a score for the digest of an address, for a signed-in account and for a browser that has passed its verification, built from events such as requests arriving faster than a person can make them, sign-in attempts that continue after a lock-out, attempted registrations beyond the limit for one address, requests for paths only scanners ask for, and content of new accounts blocked by automated review; when the score reaches a threshold, the visitor or account is asked to pass a verification before it continues. It is built so that people who share an address with someone else, as on a mobile network, are not stopped for what that someone else does. Section 12 sets out what is counted, who is assessed on which score, what the verification consists of, how long anything is kept — apart from a referral to an administrator, and the stops, waits and temporary blocks still in force, which are kept in the database until they end so that a restart does not lift them, nothing is written to disk, and nothing outlives three hours of inactivity or a restart — and what Kitguard cannot do: it restricts no account and removes no content. A signed-in account that is stopped again after passing the verification three times within an hour is not made to wait; it is referred to an administrator, who decides whether anything is done. Section 16(c) now says that the hCaptcha script is also loaded on the Kitguard page. This revision also corrects the service rather than the Policy: while bot protection was enabled, the service had been loading the hCaptcha script on every page, which Section 16(c) said it did not do, so hCaptcha could see the address and the browser of every page view; it now loads that script only on the pages this Policy names. Because this revision adds processing users were not told of, users are asked to accept it before continuing to use the service.
3 October 2026 — Disclosed the browser identifier and the bans built on it, and extended login records to carry it. The service has for some time placed a random identifier in each signed-in user's browser, kept a list of the browsers each account was used from, and refused requests from the browsers that a terminated account had used. This Policy said the opposite: that no identifier was placed in the browser to recognise it again, and that Clovera did not try to tell that two sign-ins came from the same browser. Sections 2(b), 11, 12 and 17 now describe what the service does. In the same revision the identifier is given at the moment a user signs in or registers rather than on the following page, a digest of it is written to each login record, and administrators can see which accounts have signed in from the same browser, so that accounts opened to evade a ban, or run by one person to manipulate or harass, can be found. A shared browser is shown to administrators as a lead and never acted on automatically. Nothing derived from the IP address is added: Clovera does not return to using addresses to link accounts, because behind proxies and mobile carriers they linked accounts that had nothing to do with each other. Because this revision discloses processing users were not told of, and adds a new use of it, users are asked to accept it before continuing to use the service.
15 September 2026 — Recorded web search in the KittenAI chat assistant, in a new Section 15(b-bis). The assistant can now look something up while answering, which means the substance of a question put to it may reach Google Search and not only the model, and the pages an answer was drawn from are kept with the reply so that it can be checked. The feature is confined to the chat assistant and to exchanges a user starts: moderation, translation, summaries, the Catch-Up digest and the serious-crime screen cannot search, so nothing written to another user is turned into a search query. It is on unless the operator switches it off. Because this discloses a way a user's own words may be shared that they were not told of, it is part of the revision users are asked to accept.
15 September 2026 — Extended the serious-crime screen in Section 15(e) to content written in a community's channels, and rewrote that Section to describe two switches rather than one. Until this revision the screen reached only direct and group messages, and only where the operator had enabled it; a community's messages, forum threads and forum replies were read by an automated process only where the owner of that community had enabled the general moderation described in Section 15(c). That left the decision whether a community was screened for grave crime with the person running it, which is the wrong person to ask. Content written in a community is now within the serious-crime screen wherever it is written; the community moderation setting continues to decide only whether the platform rules are applied there by an automated process, and it no longer reaches this screen at all. The switch for direct and group messages is unchanged and remains off by default. The question asked, the closed list of categories, the one-item-at-a-time transmission without identifiers, the discarding of everything where no category is found, and the rule that the screen removes nothing and can take no action of its own are all unchanged and now apply to both bodies of content. Section 15(e) records two further limits that were not written down before: a file attached to something is never opened or transmitted by the screen, and a finding is excluded from the counts the account, community and group review in Section 15(d) works from, so it cannot reach an account or a community other than through a human administrator reading the case. A case opened over content written in a community records the community and the channel it was written in, as a case over a group message already recorded the name of the group chat. The in-app notice in Settings -> Privacy now describes this screen as well. Because this revision allows an automated process to read content in communities where nothing automated read it before, users are asked to accept it before continuing to use the service.
14 September 2026 — Described parts of the service this Policy had never mentioned, and completed two lists that were incomplete. Calls, voice channels and screen sharing are described for the first time: Section 2(f) says what is kept about them, Section 8 says that the sound of a call and the picture of a shared screen travel through Clovera's own server rather than between the participants directly or through any third party, that no copy is made and nothing is recorded, and Section 14(e) says who can hear a call. Section 8 also states what is not encrypted at rest, which it had described only for message text: no uploaded file is encrypted, including a photograph, a video, a recorded voice message or a document attached to a direct message, and neither are a blog article's title, a message waiting to be sent later, a conversation with the KittenAI assistant, profile text, or the names of communities, channels and groups. Section 12 adds the two further records in which a digest of an address is kept and which it did not list: a request to reset a password approved from another device, where the digest is compared with the digests of that account's own sessions so that the person approving it is told whether the request came from an address the account has used, and the rate-limit counters. Section 15 records that a user may attach one of their own conversations to the KittenAI assistant, that the assistant's conversation is stored in plain text and sent back to Google as context until the user clears it, and that no KittenAI feature is applied to a call. Section 2(a) adds the optional birthday day and month, and Section 10 says why that still leaves Clovera unable to verify an age. Section 16 says what a push notification contains, and Section 17 names what erasure removes in the records added here. Nothing in this revision adds any processing; it describes processing that was already taking place. Because it discloses uses of personal data and an audience for content that users were not told of, they are asked to accept it before continuing to use the service.
14 September 2026 — Corrected this Policy against the service as it is now built, after checking each factual claim in it. Sections 12 and 13 were the substance of it. Login records no longer contain anything derived from the IP address of the connection — no digest of the address, no digest of the surrounding network range, no network operator and no network category — and the passages that said they did have been rewritten to describe the four records in which an address digest is in fact kept. The browser security identifier that the former Section 14 described no longer exists anywhere in the service: no identifier is placed in a user's browser to recognise it again, that Section has been removed, and Section 11 now says so in terms. Section 13 corrects two statements about "Keep me signed in on this network" that were not true of the service: the session is restored by the device cookie alone and not by the address the request comes from, and the address digest stored with the token is used, if the account is later banned, to record that address as banned — so it is not, as this Policy previously said, used solely for session continuity. The legal basis for that second use is stated separately from the consent relied on for the feature itself. Section 14 is new and sets out who can read what a user writes, which this Policy had never addressed: that a public post, a blog article and the front page of a publicly listed community are readable by anyone and offered to search engines, that the channels and forums inside a publicly listed community are readable by anyone holding the link but kept out of search indexes, and that guest reading of such a community is on unless its owner turns it off. Section 15 no longer says that using a KittenAI feature amounts to the explicit consent the KVKK requires for a cross-border transfer. Section 18 names the authorities a complaint may be made to. Section 8 gains what this Policy had never said: what Clovera does if personal data is breached, whom it notifies and within what period, and how a notice can reach users at all when no contact details are held for them. Two notices were added to the service at the same time, and are recorded here because they are new uses of a user's account: a user who files an abuse report is now told inside the service when it has been reviewed and whether it was acted on, and a user whose content an administrator removes is now told inside the service that it was removed and how to contest that. Nothing here adds any processing, and the corrections to Sections 12 and 13 record less collection than this Policy previously described; because Section 13 discloses a use of personal data that users were not told of, and Section 14 discloses an audience for their content that they were not told of, users are asked to accept this revision before continuing to use the service.
14 September 2026 — Rewrote Section 8. Group messages, community channel messages, forum threads and replies, and poll questions and options are no longer encrypted at rest; they are stored in plain text. Direct messages between two people remain encrypted at rest, as do post bodies, post comments, blog articles and their comments, and the cached translations of direct messages. Nothing new is collected, no new content is transmitted to any processor, and the automated review described in Section 15 covers exactly what it covered before; what changes is the form in which group and community content sits in the database and, with it, what this Policy can honestly claim about it. The stored copy that survives a user's own deletion, described in Section 7, is therefore plain text for a group or community message and remains encrypted for a direct message. Because this revision lowers a security measure applied to content users have already written, it is brought to users' attention and acceptance is sought before it takes effect for them.
13 September 2026 — Added Section 15(e), the serious-crime screen for messages. Until this revision, no automated process read a user's direct messages or group messages at all, and Sections 15(c) and 15(d) said so. Clovera can now be configured by its operator to put the text of each direct and group message to KittenAI with one question — whether the message is a step in organised or other grave crime, in the closed list of categories set out in 15(e). The screen is off by default and does nothing unless the operator switches it on. It sends one message at a time, with no name or identifier attached; it keeps nothing where no category is found; where one is found it opens a case for a human administrator holding the date, the category, the sending account, and an excerpt of at most 200 characters, stored encrypted. It cannot delete a message, block its delivery, or restrict an account: the message is delivered and stays until a human decides otherwise. General moderation of private conversation is expressly not within it, and insults, hate, harassment, and other unpleasant but non-criminal content are outside its scope. Because this revision allows a new category of content — private correspondence — to be read by an automated process and transmitted to a processor, users are asked to accept it before continuing to use the service.
12 September 2026 — Extended automated content moderation in Section 15(c) to profile text, to the name, description, welcome message, and channel names of a community, and to the name of a group chat, all of which are now read by KittenAI. Added Section 15(d), describing the KittenMOD sweep: an automated review of accounts, communities, and groups that counts patterns of use on Clovera's own servers — publishing frequency, unanswered direct messages, group additions, blocks, reports, and a match between an address digest and a ban record — without opening any private or group message, sends nothing beyond the texts listed in 15(c) to Google, and produces a case for a human administrator. Stated that such a review may place a community on hold, reversibly, pending human review, and that it never suspends an account, closes a community, or dissolves a group by itself. Because this revision sends new categories of content to a processor and adds a new use of usage data, users are asked to accept it before continuing to use the service.
13 August 2026 — Described in Section 7 how abuse reports are used to measure unlawful use of the service: the reporter-chosen category and the review outcome recorded with each report, the erasure of a settled report's free-text explanation after 180 days, and the daily automated-moderation counters that carry no user identifier, content, or address. This revision adds a retention limit and an anonymous statistic and collects nothing new about anyone, so it is published without seeking renewed acceptance.
13 August 2026 — Rewrote Section 17 because account erasure is now a self-service control: an account can be erased from settings, immediately and irreversibly, where the previous revision said no such control existed and that erasure was carried out manually on request. Set out what that erasure removes in the terms the service actually implements, adding the recovery keys and creator bots it destroys and the earlier-deleted messages it finally purges, and stated plainly the three things it does not remove and why. Recorded that an account owning a community with other members must hand it over or close it first, so that erasing one account cannot destroy other people's content. Added that Clovera keeps a record of each erasure which identifies no account, as the retention and destruction obligation in the KVKK Notice requires. This revision expands what users can do without asking and removes nothing from them, so it is published without seeking renewed acceptance.
26 July 2026 — Revised the KVKK Privacy Notice referred to in Section 15 and made it one of the documents each user confirms at registration and on re-acceptance. Corrected this Policy against the service as actually built, following a review of every factual claim in it: named every third party that receives personal data and what each one receives (new Section 16, covering hosted fonts, bot protection, and push delivery, none of which were previously disclosed); stated that no email address is collected and what follows from that for notices and identity verification; removed the statement that approximate location is derived from IP addresses, which Clovera does not do; described the logging of registration addresses, per-session address digests, and failed login attempts, which were not previously described; corrected the statement that users who decline "Keep me signed in" have no address digest stored for their sessions; corrected the described scope of automated moderation, which also covers non-public posts, comments, blog articles, server icons, and bot messages; replaced the undertaking to obtain consent before storing the browser security identifier with an accurate account of the basis actually relied on; described what a message deletion does and does not destroy; and added Section 17 explaining that account erasure is carried out on request rather than by a self-service control.
25 July 2026 — Introduced the browser security identifier described in Section 14. Extended the login records described in Section 12 to include the network category and network operator of the connection. Changed the digest stored in place of an IP address to a keyed digest, so that it can no longer be reversed into the original address. Users were asked to accept these changes before continuing to use the service.
8 July 2026 — Previous revision.
