Security
Your data, under control
What actually protects your account, your files and your conversations. Only measures that are really in place — no certifications we don't hold.
Last updated
Sign-in and sessions
What signs your session, how the second factor works, and what happens when a session has to be revoked.
Go to section →Data in transit and at rest
How data travels, where files live, and what we deliberately don't keep at all.
Go to section →Code and supply chain
What every change has to survive before it reaches production.
Go to section →Providers and your data
What reaches the models, what never does, and what enforces that technically.
Go to section →Access
Sign-in and sessions
What signs your session, how the second factor works, and what happens when a session has to be revoked.
- Passwords
- Passwords are stored as PBKDF2-HMAC-SHA256 hashes with individual salts. At sign-in the server processes the entered password for verification; storing the original is unnecessary.
- Two-factor authentication
- TOTP per RFC 6238 — any standard authenticator app works. Backup codes are issued alongside it in case you lose the phone; each one works exactly once.
- Passkeys
- WebAuthn supports device-key sign-in. The private key remains with you; the server checks the signed response and information supported by the authenticator.
- The session cookie
- The session cookie is signed and HttpOnly; HTTPS uses Secure. SameSite settings depend on the surface, with separate Telegram Mini App settings.
- Revoking every session
- Each account carries a session version. Changing or resetting the password, signing out everywhere, and deleting the account all bump it — every previously issued cookie stops being accepted at once. A plain sign-out ends only the current session and leaves your other devices alone.
- Brute-force protection
- Rate limits on every sign-in endpoint, plus an account-level lockout after repeated failures — it isn't tied to an IP, so rotating addresses doesn't get around it. Passkeys, OAuth and Telegram are exempt: there is always a way back into your own account.
- Separated signing keys
- The session, the second-factor challenge, the passkey challenge and the bot link each use a different derived key. A token minted for one purpose will not validate for another — and that is pinned by tests.
- Alerts on access changes
- Changing your password, enabling or disabling the second factor, adding or removing a passkey notifies the account owner through two channels at once — in the app and on Telegram, with the IP address. They cannot be switched off: a silent account takeover should never be a configurable option.
- Security event log
- Sign-ins and failed attempts, lockouts, second-factor activity and every operator change to an account are written as individual records with IP and user agent.
Infrastructure
Data in transit and at rest
How data travels, where files live, and what we deliberately don't keep at all.
- Encryption in transit
- All traffic runs over TLS only. https responses carry HSTS for a year including subdomains, so the browser stops even attempting the unencrypted protocol.
- Security headers
- Security headers and Content-Security-Policy are centralized. Telegram Mini App has separate embedding rules; browser capabilities are restricted according to the surface.
- Private file storage
- Private-file access is checked; some uploads use temporary signed links. Avatars, shared links and published works have separate public routes.
- Minimising what we keep
- Text is extracted for processing. Temporary chat uploads have a30-day availability window, which does not cover avatars or durable generations. Physical deletion depends on storage.
- Service isolation
- Services are separated and resource limited; the database may be hosted separately. Limits reduce interference but do not guarantee that every failure is independent.
- Image upload checks
- A file's type is determined from its contents — not from the extension, and not from what the browser claimed. An executable renamed to .png does not become an avatar.
- Validation at the boundary
- The fields a request is allowed to change are listed explicitly — an extra field in the body is ignored rather than applied. File paths are normalised and outbound links are checked by scheme.
- Backups
- A database dump is taken before every deploy, so each update has a point to return to. A scheduled backup script with rotation ships with the project and is enabled on the server side.
Engineering
Code and supply chain
What every change has to survive before it reaches production.
- A blocking gate on changes
- The project includes tests, linters, builds and dependency checks. A particular release is evidenced by its CI run; this page does not replace release-status verification.
- Dependency auditing
- Automated dependency checks help identify known vulnerabilities. They do not guarantee detection of every issue or immediate updates to every package.
- Guard tests for invariants
- Some tests check a broken rule rather than a wrong result: heavy synchronous work inside async code, a diverging migration graph, a table left out of the account-merge registry. Those failures are invisible to the eye and expensive to find late.
- Secrets outside the repository
- Keys and the production environment are never stored in code. In production a missing session-signing key is not a log warning — the application refuses to start.
- Payment details
- Card details are entered on the payment provider's page, not ours. Card numbers never reach us, so there is nothing for us to store.
Models
Providers and your data
What reaches the models, what never does, and what enforces that technically.
- Provider training and retention
- OpenLearn does not train its own models on conversations. External provider terms and route settings differ; universal no-training and zero retention are not guaranteed.
- No selling of data
- Conversations are sent to AI suppliers to perform requests. Recipients and purposes are described in the Policy; transmission does not make data anonymous.
- Per-model kill switch
- Any model can be switched off instantly: it disappears from the catalogue and from the composer's picker, rather than quietly failing somewhere deeper.
- One platform key
- AI uses platform keys. Content may be accompanied by technical user and request identifiers, memory and personal instructions; unlinkability to an individual is not guaranteed.
Sub-processors
Who receives data, and why
Data is transmitted for the selected functions. These categories are not a complete register of legal entities or countries; see the Policy.
| Processor | What's shared and why | Data location |
|---|---|---|
| OpenRouterAI | AI routing including speech transcription and synthesis | International processing; route dependent |
| Model providersAI | Request content, context, attachments and technical IDs for results | Depends on the ultimate processor |
| Payment providersPayments | Amount, currency and operation ID; methods from the payment catalog | Depends on the selected method |
| ResendEmail | Address and service email content; advertising with consent | International delivery |
| Timeweb CloudInfra | Application, database, files and backups | Primary deployment: Russia |
| External sign-in and TelegramInfra | Sign-in profile; bot/Mini App messages when used | Under the selected service terms |
| Search and network intermediariesInfra | Search queries, fetched pages and external API traffic | Depends on routes and contractors |
Compliance
Regulators and user rights
European Union
Support accepts access, correction, deletion and export requests. GDPR applicability and additional procedures require separate assessment; compliance certification is not claimed.
Russian Federation
The Policy describes processing and rights under Russian law. This page does not itself establish regulatory notifications or the lawfulness of every transfer.
California, USA
Collection and recipients are described in the Policy. California law applicability requires separate assessment; unconditional CCPA compliance is not claimed.
Data lifecycle
What's stored and how to delete it
- Chat historyKept in your account until you delete it. You can erase any chat manually.
- Uploaded filesTemporary chat uploads have an availability window of up to30 days. Extracted text and durable files are retained separately; physical deletion depends on storage rules.
- AvatarsStored separately from temporary uploads. Replace or remove an avatar in settings; account deactivation does not prove file erasure.
- Account deletionDeletion marks the account deleted and ends the current session. This is not proof of physical erasure of all data, backups or publications. Contact support about deletion.
Vulnerabilities
Found something? Tell us
Vulnerability reports go to the front of the queue and every one of them gets an answer.
Please include reproduction steps, and give us time to close the issue before publishing it. We don't run a bounty programme — but we will reply and tell you what we did.
Privacy questions?
Read the full policy or write to us — we'll answer to the point.