TarnVeil Privacy Policy

TarnVeil is a messenger with text chat, direct and group messages, voice messages, voice and video calls, spatial audio rooms and communities. It is available in the browser and as an app for Windows (desktop) and Android. This policy describes what data we process, why, and how you can control it.

1. What data we process

• Account: username, display name, avatar and custom status (optional), password hash. We do not store the password itself — only a cryptographic hash (bcrypt). No email address and no phone number are required or requested to sign up.
• Content: messages in channels and communities, direct and group messages, discussions, attachments (files, images, voice messages), reactions, pinned messages and replies.
• Direct messages: one-to-one conversations are protected by end-to-end encryption (E2EE) — see section 7. In that mode the server stores only the encrypted text and attachments and cannot read them.
• Voice and video: streamed between the participants of a call or audio room in real time (through our own TarnMedia SFU) and not recorded or stored by us. In spatial rooms only the participants' notional coordinates (their position on the “map”) are synchronised; no audio is saved anywhere.
• Service data about conversations: read receipts, the “typing…” indicator, online / last-seen status, your favourite contacts and notification settings. These exist so that the corresponding features can work.
• Sessions and security alerts: the list of your active devices (device description, IP address, sign-in date) and records of sign-ins from a new device or of account recovery. More about IP addresses in section 4.
• Technical information: the device token for push notifications (FCM).

2. Guest accounts

“Continue as a guest” is not an anonymous browsing mode: it creates a real account in our database, just without a sign-up form.

• How it works: the server generates a username of the form гость-xxxxxx, and your device generates a random password that is never shown to you. As a result, a guest account can only be entered from that device, and only for as long as the browser remembers the session.
• What that means in practice: clearing site data, switching browsers or devices, or using private browsing means losing access with no way to recover it — we hold no email address or phone number that could restore such an account.
• What is stored: everything you write as a guest — messages, attachments, community membership — is stored exactly as it is for a regular account and stays in the database until the account is deleted. Unused guest accounts are not deleted automatically.
• How to keep it: a guest account can be claimed — set your own username and password in the settings. Your conversations, communities and settings are kept, and the account becomes an ordinary one.
• Same rights: a guest can delete their account just like any other user (section 8).

3. Why we use it

• To run the application: deliver messages, calls and notifications, and display your profile, friends and communities.
• For security: protection against spam, password guessing and abuse.

We do not sell your data and do not use it for advertising.

4. IP addresses

Your IP address is visible to the server on every request — without it the network simply does not work. Here is what we do with it:

• Temporarily, for protection: rate limiting on sign-in, sign-up and other actions, to make password guessing and spam harder. Those counters live for minutes and never reach the database.
• In the record of an active session: when you sign in, the IP is stored next to the device description. This is your own list of sessions in Settings → Account: you can see where your account is open and end any session. The record, IP included, is deleted when the session ends — by you, by signing out, or by a password change (which ends every session at once).
• In security alerts: a sign-in from a new device, or an account recovery, creates a record with the device description and IP so that you can notice a sign-in that was not yours. These records stay in your history until the account is deleted.

We do not derive your location from your IP, do not build a profile on it and do not pass it to third parties. Note that your IP is also visible to the technical providers your connection passes through (hosting, network) — as it is on any website.

5. Cookies and local storage

The application itself uses no cookies. Everything it needs is kept in your browser's local storage and is not sent anywhere on its own:

• The sign-in token — so that you are not asked for a password every time.
• Encryption keys for direct messages (IndexedDB). The private key never leaves the device; the server holds only a backup copy of it, sealed as described in section 7.
• Settings: interface language, microphone processing mode and audio settings, per-person volumes, hidden conversations, message translation state, and which release notes you have already seen.

Clearing site data removes all of it, encryption keys included. After that, older encrypted messages cannot be read on a new device until the key is restored — from your recovery code or by contacting the operator (see section 7).

Cookies appear only before you sign in. The public pages and the sign-in screen run a Yandex.Metrica counter, which sets its own cookies. The counter is switched off and removed from the page the moment you sign in: inside the application — in conversations, calls and settings — there is no analytics at all. See section 6.

6. Who the data is shared with

• Firebase Cloud Messaging (Google) — to deliver push notifications to your device. For encrypted direct messages the push carries only a neutral “🔒 New message” without any text.
• Yandex.Metrica (Yandex) — web analytics on the public pages and the sign-in screen: visits, referrers, clicks and session recording (Webvisor), so that we can see where people get stuck on first contact. Metrica receives your IP address and sets its own cookies. The counter does not run after you sign in, so conversations, calls and settings never reach analytics. Yandex terms: yandex.com/legal/confidential.
• Klipy — GIF search. The text of your query reaches them through our server, so the service cannot see who is searching. The GIFs themselves are loaded by your browser directly from their CDN (static.klipy.com), and Klipy sees your IP address and browser details in the process, as does any site you load an image from. Nothing about your account and nothing from your conversations is passed to them.

There are no other transfers to third parties.

7. Storage, encryption and protection

Data is stored on our server. All network connections are protected by TLS (HTTPS/WSS). Passwords are stored only as hashes.

• Direct messages (E2EE): once both participants have set up encryption keys (which happens automatically when signing in on a device), the conversation and its attachments are encrypted on the device — the server receives and stores only ciphertext and cannot read the contents by itself. The app states the encryption status of every conversation honestly (the lock icon). If the other person has not set up encryption yet, messages are protected by server-side encryption (see below) but are technically accessible to the server — which the lock status says plainly.
• An important exception — account recovery by the administrator. So that a forgotten password does not mean losing your conversations forever, the app keeps a backup copy of your private key on the server. It is sealed to a separate administrator recovery key whose private half is kept offline and never reaches the server: a database leak alone does not expose your messages. However, the operator of the service, holding that offline key, can technically restore your key and gain access to your direct messages. This is a deliberate trade-off: without it, a forgotten password would cost you your entire history. In practice recovery is performed at the request of the user themselves, requires the separate offline key, and is recorded in the administrator action log. This backup cannot be disabled in the app. If that trust model does not suit you, do not use the service for conversations that cannot be entrusted to its operator.
• Group conversations and community messages: encrypted on the server at rest (AES-256-GCM). That protects the data in storage but, unlike direct messages, it is technically accessible to the server (full group end-to-end encryption is not implemented yet).
• Access: direct messages are accessible only to the people in the conversation; community messages, to the members of that community.

8. Deleting your account, and backups

You can delete your account yourself: Settings → Account → Delete account. The confirmation is irreversible, and we will not restore the account on request.

Deleting the account removes the following from the running service:

• your messages, direct and group conversations, discussions and attachments;
• the communities you created;
• device sessions, security alerts and push tokens;
• the backup copy of your encryption key — after which nobody can decrypt your conversations, the operator included.

An honest note on “permanently”. We take a daily backup of the database and of uploaded files — otherwise a single disk failure would cost every user their history at once. Backups are kept for 14 days on the server and for up to 30 days on a separate medium held by the operator, off the server, and are then erased automatically. So the precise statement is this: your data disappears from the running service immediately and for good, and from backups within a month. Backups exist only to restore the service as a whole after a failure; we do not pull individual deleted accounts out of them for anyone.

Separately: messages you sent to other people are part of their conversations too. Copies kept by the people you talked to — a screenshot, for instance — are not covered by deleting your account.

9. Your rights and control over your data

• Changing your password: in Settings → Account. Changing the password ends sessions on other devices, and your encryption key is re-wrapped under the new password.
• Sessions: a list of active devices, with the option to end any one of them or all at once.
• Blocking: you can block any user — they will not be able to message or call you.
• Reports: you can report a user or a message, and moderators will review the report.
• Deletion: see section 8.

10. User content and moderation

Content is created by the users themselves. Insults, threats, illegal material and spam are prohibited. Moderators may remove such content and block offenders in response to user reports. Note that the contents of direct messages with end-to-end encryption enabled are not read by the server and are not available to moderators in ordinary work — direct messages are moderated only on reports to which the reporter themselves attaches a screenshot of the message. The only way for the operator to obtain access to the contents is described in section 7 (“Account recovery by the administrator”).

11. Age requirements

You must be at least 13 years old to use TarnVeil.

If you are in the European Economic Area or the United Kingdom, you must be at least 16, unless your country sets a lower age — never below 13 — and your parent or guardian has given consent. In Russia, where the service is operated, the recommended minimum age is 12, but the higher thresholds above apply to users in the regions named.

We do not knowingly collect data from children below these ages. If you believe an account was created by a child who is younger, tell us and we will delete it.

12. Changes to this policy

We may update this policy. The current version is always available at this address, with the date of the last update.

13. Contact

TarnVeil is a learning project. For privacy questions, bug reports and vulnerability reports, use the Issues section on the project page on GitHub: github.com/Amesu-afk/TarnVeil.