Privacy Policy

Last updated: October 10, 2026

This Privacy Policy describes how Vitalii Sosin PR Beograd ("Company," "we," "us," or "our") collects, uses and protects your information when you use oChat — the oChat application for iOS, macOS and Android (the "Application" or the "Services"). By using the Application you acknowledge that you have read and understood this Policy.

The three builds are one application and process the same data for the same purposes. Where Android differs from iOS and macOS — in a sign-in option, in a service that delivers notifications or takes payment, in an SDK it embeds — the difference is named at the point where it applies, rather than left for you to infer.

The Data Controller is Vitalii Sosin PR Beograd, a sole proprietor (preduzetnik) registered in the Republic of Serbia. Full registration details are provided in Section 11.

We aim to process personal data in line with the EU General Data Protection Regulation (GDPR) where applicable, the Serbian Law on Personal Data Protection ("Zakon o zaštiti podataka o ličnosti") and other applicable law.

1. What Information We Collect

Information you provide

• Sign-in identity. You sign in through Firebase Authentication. Which options are offered depends on the platform: on iOS and macOS, Apple, Google or an email address and password; on Android, Google or an email address and password — Sign in with Apple is not offered there. What reaches us is the account identifier that provider issues for you, and the display name you let it pass on. If you sign in with email, the password is kept by Firebase Authentication, not by us. It does pass through our servers on its way there — the application sends sign-up, sign-in and password-reset requests to our servers, which forward them to Firebase — and we do not store it. We do not ask for a phone number and do not store one, and we do not receive your Apple or Google password — though where the Russian routing applies, the page you type that password into is delivered through a domain of ours, which Section 3.3 sets out in full. If you use Apple's "Hide My Email", we never see your real address either.
• Your email address. The sign-in provider passes your email address to the application, which shows it to you on your own account card. When you sign in with Apple or Google, it is not sent to our own servers; with email sign-in it is, as the end of this item says. Either way, our database has no column to hold it. That is narrower than "we never see it", and the difference is worth stating: sign-in runs through Firebase Authentication in a project that belongs to us, so your address sits in that project's own list of users, which we can open and export as its owner. What your address stays out of is the database where your profile, your chats and your messages live. With email sign-in your address reaches our servers because you type it to sign up, sign in and reset your password, and we send to it the emails that carry a six-digit code — to confirm the address when you sign up, and to reset a forgotten password. While such a code is outstanding, our servers keep the address alongside it, and the code itself only as a keyed hash; both expire after ten (10) minutes, or sooner once the code is used.
• Profile. Display name, username, short bio and avatar image, if you set them.
• Message content and attachments. The text of your messages and any files, images or voice notes you send pass through our servers encrypted by your device, and we keep them only until every device they are addressed to has received them, and never longer than thirty (30) days. Your history is kept on your devices, not by us, and in the current version of the application your Saved messages never reach our servers at all. See Section 5 — this is the part of the Policy you should read most carefully.
• Support correspondence and reports. What you write to our support team, in the clear (Section 5.7). Reports about a message, a group or a channel could be filed while public groups and channels existed; they no longer do, and a report already filed is kept as Section 9 says.

Information collected automatically

• Device identifier, device model, operating-system version, application version, locale and platform. The identifier is one the application generates for itself — a random value kept in the device's own protected storage, the Keychain on iOS and macOS and the Keystore-backed store on Android. It is not a hardware serial and it is not an advertising identifier; on Android the advertising-identifier permission is stripped out of the built manifest, so the application could not read one even if a library asked.
• The name of your device, as the device itself reports it, so that the list of your signed-in sessions says "Pixel 9 Pro" rather than a row of identifiers. Worth knowing before you read on: many people name a device after themselves, and a device called "Anna's phone" tells us a first name we never asked for. You can rename the device in your system settings, and the new name replaces the old one the next time the application reports in.
• Push notification token, so that notifications can reach your device: Apple Push Notification service on iOS and macOS, Firebase Cloud Messaging on Android. On Android the same token is also recorded as the call token, because Google's delivery system decides how urgently to wake a device from its power-saving state, and a call invitation that arrives at ordinary priority arrives minutes late.
• Connection data: IP address at the time of connection, and the timestamps of connection, last activity and last-seen status.
• Approximate location, derived from that IP address. We do not ask for, and the application does not hold, any location permission on any platform — there is no GPS reading anywhere in it. But an IP address implies a place, and two things use that: our servers read the country code that Cloudflare attaches to your request, in order to decide whether to serve you from the Russian mirror (Section 3.3); and our product analytics resolves the same address to a country and a region. City, network operator and the address itself are switched off there. Country and region are not, and rather than argue that a region is not a location, we call it what it is: approximate location, collected in every build, for as long as you use the Application.
• A record of every call. A call writes a row that outlives the conversation it describes: who called and who was called, when it was created, answered and ended, how long the talking lasted, whether it was audio or video, how it finished (hung up, declined, missed, busy, failed), the region the caller connected from, and whether the media went directly or through a relay. What is not in that row is the call itself. Audio and video travel between the two devices encrypted and never reach us, and the material that sets a call up — the offer, the network candidates, the key fingerprints — is sealed on your device for your correspondent's device, so we pass it along without being able to read it or forge it, and it is gone the moment the call ends. The row is what your call log and the call bubble in your chat are built from.
• Technical logs and crash/error diagnostics.
• Subscription state and purchase identifiers received from Apple, from Google Play, or from our web payment partner.

What we do not collect

The Application contains no advertising SDKs and nothing that profiles you for marketing. It reads no advertising identifier on any platform: on iOS and macOS it does not ask for App Tracking Transparency and does not touch the IDFA, and on Android the advertising-identifier permissions are removed from the manifest outright. Nothing it collects is linked with data from other companies' apps or websites.

What it does contain is product analytics and crash reporting — Amplitude, Sentry, Firebase Analytics and Firebase Crashlytics, all listed in Section 3.5. This collection is not optional. There was once a switch for it in the application's settings; it was removed, and we would rather say so here than leave the older wording standing. Diagnostics start when the application starts — before the sign-in screen that links to this Policy, which is why the link is on that screen and why this paragraph is where it is. What limits the collection is not a switch but what these services are given: an account identifier, device and version data, the names of events, and never the content of a message. Section 3.5 says what each of them gets.

This website is a separate matter, and an earlier version of this paragraph described it as barer than it is. It sets no cookies, and its fonts and its own images are served from our own domain. But it does load scripts from other companies, and some of its pages keep data in your browser:

• Every page carries Cloudflare Web Analytics, which we have switched on for this site and which Cloudflare inserts into each page as it serves it: a script from static.cloudflareinsights.com that reports the address of the page, the page you came from and how quickly it loaded. It sets no cookie and keeps nothing in your browser. Section 3.2 says more.
• The pages you can sign in on — the cabinet at /app/, the protection subscription at /vpn/ and the support page at /donate/ — load Google's Firebase Authentication library from www.gstatic.com as soon as they open, whether or not you sign in. Pressing a sign-in button also loads a script from apis.google.com and a frame from auth.ochat.club, and opens a window that goes on to Google's or Apple's own sign-in page, which keeps its own cookies on its own domain. Section 3.1 says more.
• The public feedback board at /feedback/ shows the photos and videos attached to requests straight from our storage at Cloudflare R2, or from its mirror on a domain of ours, and a file you attach is uploaded there directly from your browser.

What stays in your browser, in localStorage unless said otherwise: on the home page, the legal pages and the pages that hand a link over to the app — your theme and language choice. On the sign-in pages — a random identifier for that browser, created the first time you sign in on one of them; and, once you are signed in, the tokens of your oChat session and Firebase's own record of the account you signed in with: its identifier, your email address, the name and photo address the provider passes on, and Firebase's own tokens. Firebase keeps that record in the browser's IndexedDB, and keeps there as well, signed in or not, the dates on which its library ran and its version. Signing out on those pages deletes the session tokens and Firebase's account record; the browser identifier stays, so that the same browser does not count as a new device every time you sign in. The /premium/, /android/ and /feedback/ pages keep nothing in your browser.

2. How We Use Your Information

• To operate the Services: deliver your messages to the recipients you choose and to your own other devices, and show delivery and read states.
• To carry your history from one of your devices to another when you ask for it, and the recent history of a group to a member you add (Sections 5.12 and 5.13).
• To sign you in and keep your session valid across devices.
• To send push notifications about new messages and incoming calls.
• To set up the calls you place, and to keep the record of them that becomes your call log and your correspondent's.
• To prevent, detect and investigate abuse, spam, fraud and violations of our Terms, and to enforce them.
• To process subscriptions, purchases and refunds.
• To provide support and respond to your requests.
• To keep the Services reliable and secure, and to diagnose failures.
• To comply with legal obligations.

We do not use message content for advertising, we do not sell personal data, and we do not use your messages to train machine-learning models. The one thing we do hand to a model is a question you send to support, and only in order to answer it: Section 3.7 says what is sent, to whom, and what is kept afterwards.

3. Service Providers Who Process Data on Our Behalf

We use the following providers. Each processes data on our instructions for the purpose listed, and each has its own privacy policy.

3.1 Authentication

Firebase Authentication (Google) — accepts your sign-in and issues the token we exchange for an oChat session: Apple, Google or email and password on iOS and macOS; Google or email and password on Android. Google receives basic device and network data as part of that, and your email address, because the account being checked is one of theirs. With email sign-in it also keeps your password for that account, and our servers create and update that account in Firebase on your behalf. No phone number is involved.

Cloudflare Email Sending — sends the emails with the six-digit codes for confirming an email sign-up and for resetting a password, from [email protected]. It receives your email address and the text of that email, which includes the code.

On this website the cabinet, the protection subscription and the support page sign you in through the same Firebase project, with Apple or Google. Its library comes from Google's servers, and the frame and window that carry the sign-in are served from auth.ochat.club — a subdomain of ours that points to Google's Firebase Hosting, so what runs there is Google's code, served by Google. What the site keeps in your browser afterwards is set out at the end of Section 1.

3.2 Infrastructure, storage and delivery

Cloudflare — content delivery, edge security and rate limiting, and R2 object storage: avatars are stored there, attachments wait there until they are delivered (Section 5.3), and the encrypted archives of history transfers pass through it (Sections 5.12 and 5.13). Railway — hosting for our application servers and databases, including the support assistant described in Section 3.7.

Cloudflare also hosts this website, and measures it: Cloudflare Web Analytics, switched on for the site, is inserted by Cloudflare into every page and reports the address of the page, the page you came from and how quickly it loaded. It sets no cookie and keeps nothing in your browser.

Calls use Cloudflare for a second thing: its STUN and TURN servers are how two devices find a path to each other through their networks. When no direct path exists — and for a large share of mobile networks none does — the audio and video go through Cloudflare's relay, which therefore carries the packets and sees both addresses. It cannot open them: the media is encrypted between the devices, and the keys are theirs.

3.3 Reverse proxy for users in the Russian Federation

For users connecting from the Russian Federation, the application may route its API and media traffic through a reverse proxy hosted in the Russian Federation. That proxy terminates the TLS connection from your device, sees your IP address and connection metadata, and forwards the traffic to the same servers described above. It stores no message content of its own.

In that region the application also routes the sign-in requests themselves — the ones your device makes to Google's authentication servers — through a subdomain of ours, because those servers are not always reachable from there and the failure is a silent one. The redirection is done on both platforms, on iOS and macOS at the URL-loading layer and on Android inside the HTTP client, and the list of addresses it applies to is closed and short: the sign-in provider's, and nothing else. Say plainly what that means, because it is the same thing a proxy always means — our edge terminates those connections as well, and the exchange passes through our infrastructure before it reaches Google. What the exchange carries is the token the provider issued for you and the token it issues back.

On iOS and macOS the sign-in page itself is part of that redirection, and we are not going to dress it up. Signing in with Google there happens on a web page — Google's own consent screen, the one where you type your Google password and your second factor — and where this routing applies the application opens that page at ru-google-auth.ochat.club, a subdomain of ours, instead of at accounts.google.com. Our edge terminates that connection too, which means the page you type a Google password into is delivered to you through our infrastructure, and what you type goes back the same way. We do not read it, keep it or log it, and the application itself never receives your password — but that is a statement about our conduct, not a property of the arrangement, and the two are not the same assurance. Sign in with Apple has no such page: it is a system sheet, and nothing in it is redirected.

On Android there is no consent page to redirect. The account is picked in the system's own Credential Manager sheet, no password is typed into anything of ours, and what that build redirects is only the machine-to-machine calls to the provider's servers. Everything this subsection says about sign-in applies while the Russian routing is on; outside it the application goes to the sign-in provider directly, and the mirror is not in the path at all.

3.4 Notifications and purchases

Apple (iOS and macOS) — the Apple Push Notification service delivers notifications to your devices, and the App Store Server API provides us with your subscription status. When you ask Apple for a refund, Apple may ask us for consumption information about that purchase.

Google (Android) — Firebase Cloud Messaging delivers notifications and call invitations to your device, which means Google is handed a token identifying that installation and the notification we ask it to deliver. Google Play Billing sells subscriptions bought inside the Android application: your payment method and your billing details are Google's to handle and never reach us. What reaches us from your device is what Google Play hands it back — the purchase token, the product identifier and the package name — so that the subscription can be verified with Google and the entitlement granted to your account.

Polar Software, Inc. — merchant of record for any purchase made outside the app stores; Polar receives your billing details and handles payment and tax.

3.5 Product analytics and error monitoring

Amplitude (all builds) — product analytics: which screens are opened and which actions are completed, with an account identifier and basic device data. It exists so we can tell a feature nobody uses from one that is broken. It receives no message content, no contacts and no attachments. It is configured to withhold the IP address, the city and the network operator on iOS, macOS and Android alike; it does resolve country and region, which is the approximate location named in Section 1. One switch differs between the platforms, and we would rather name it than round it off: on Android what is turned off is the device advertising identifier, while on iOS and macOS what is turned off is the vendor identifier (IDFV) — Apple's per-installation identifier, which is not an advertising one. There is no advertising identifier to withhold on Apple platforms in the first place: the application never asks for App Tracking Transparency and never reads the IDFA, as Section 1 says.

Sentry (all builds) — crash reports and error diagnostics, which may include a user identifier, request metadata and stack traces. It receives no message content. On Android it is the crash reporter.

Firebase Analytics (Google) (Android) — the same events, under the same names, in a second dashboard, with an account identifier and the device data Google's SDK collects for itself. In the Android build collection is switched off in the manifest and is turned on only once the configuration hands the application its analytics keys. On iOS and macOS the application sends it nothing: it logs no event there and sets no identifier there, and on those platforms the events described above go to Amplitude alone. The library is linked into the Apple builds all the same, and nothing in them switches off the automatic measurement Google's own SDK performs once Firebase is configured. That is why this line now names a platform instead of saying "all builds", which read as though a second copy of our events existed on Apple platforms. It does not.

Firebase Crashlytics (Google) (iOS and macOS) — crash reports from the application, for the same purpose as Sentry and with the same limits. The library is also present in the Android build, but its collection is switched off in that build's manifest and nothing turns it on, so on Android crashes go to Sentry alone. We mention a library that collects nothing because it is in the package either way, and you are entitled to know what is in the package.

Event names and property keys are a closed list — the application cannot send a free-form field — and every value passes through a scrubber that replaces anything shaped like an email address, a phone number, a token or a recovery code before it leaves the device. None of these services is used for advertising, and none receives what you write.

3.6 Demo mode

On Android the application can show a demo: a made-up account with made-up conversations, reachable from a button on the sign-in screen. It exists because signing in there requires a Google account, and a person reviewing the application — at Google Play, or you, before you decide to sign in — should be able to see what it is without creating one. The iOS and macOS builds do not offer it yet. The button appears only while we have the demo switched on from our servers, and the demo replaces the real application entirely; nothing you do in it touches a real account, because in demo mode the application has no session and no keys.

The one thing worth declaring: the demo's photographs and portraits are fetched from two third-party image services, picsum.photos and i.pravatar.cc. Those requests come from your device, so those two services see your IP address and the fact that a request was made, as any website would. They receive no account data, because in demo mode there is none. Outside demo mode the application never contacts them.

3.7 The assistant that answers support first

Google (Gemini) — when you write to support, the first answer is written by an assistant built on a large language model, not by a person. The application says so above the first message you send, and this Policy says the rest: to produce that answer, the text of your question is sent to Google's Gemini API and processed on Google's own infrastructure. Google is a United States company and we do not pin the request to a region, so treat the destination as outside the European Union (Section 8). The models in use today are gemini-2.5-flash for the answer and gemini-embedding-001 for finding the right article in our help base.

What goes to Google is the text you wrote, and nothing else that identifies you: not your account identifier, not your username, not the rest of the conversation. The assistant service keeps a log of questions and answers so that we can tell a useful answer from a bad one; that log carries no account identifier either, and it is erased after fifteen (15) days. The link between an answer and the person who asked is kept by us, in our own database, with the rest of the support conversation.

We ask Google to do one thing with that text: answer the question. What it is permitted to do with it beyond that is set by Google's own terms for the Gemini API and not by this Policy — which makes a support question the one thing you write in oChat whose fate is partly in someone else's hands. That is the reason this subsection exists, and the reason the paragraph below tells you to write accordingly.

A person takes the conversation over when the assistant has no reliable answer, when you report something broken, or the moment you ask for a specialist — and the operator then sees the whole conversation, the assistant's replies included. We can also switch the assistant off entirely, in which case support is people from the first message. The practical consequence for you is the one in Section 5.7: a support question should be written on the assumption that a third party's model will read it, because it will.

3.8 Operational alerts in Telegram

Telegram — our servers send operational alerts to a private Telegram chat that our team reads: an account has asked to be deleted, an account was closed automatically, a payment failed, a background job crashed. They go out through Telegram's Bot API, and Telegram is not established in the European Union (Section 8).

These alerts are not anonymous, and we would rather say so than leave the impression that they are. The header of an alert carries the account identifier — the internal UUID — of the person the event concerns, and the body carries a short description of the event, which for a deletion or a block names what happened and when the purge falls due. What they do not carry is message content, contacts or attachments, and the identifier in them is the internal one, not your phone number. Section 9 does not apply to them. The retention periods there describe our own databases and logs; an alert is a message in a chat, and it stays in that chat until someone deletes it from there. We say this because a truthful retention section cannot promise thirty days for a copy that sits somewhere we do not sweep.

4. Your Address Book

Your contacts never reach us, in any form — not raw, not hashed, not salted. There is no contact discovery: we cannot tell you which of the people in your phone already use oChat, because we never learn who they are. Should the app ever offer to help you invite someone, it will do so through your operating system's own sharing or contact-picker screen, which hands us nothing — you pick a person, your OS opens your messaging app, and the invitation goes from you, not from us.

You find people by username: you type the one they gave you, or you open a link they sent. That is the whole mechanism. It is less convenient than matching an address book, and it is the deliberate trade: an address book is a map of everyone you know, including people who never installed anything of ours and never agreed to anything.

5. Data Storage and Security

5.1 In transit

All traffic between the Application and our servers, and between our servers and our providers, is encrypted with TLS.

5.2 Every conversation is private

This is the most important thing in this Policy, so it is stated before anything else:

• Every conversation in oChat is end-to-end encrypted, always. A conversation is either a one-to-one chat or a group, and both are private: there is no switch that turns encryption off, and there is no way to make a conversation public. That is a statement about the journey and about our servers; what your own device keeps is Section 5.10.
• Channels and public groups no longer exist. Channels can no longer be created, and existing channels are being closed and deleted together with their content. Groups that used to be public are being made private: their members stay, the public address is released, and from then on a group is joined only by being added by a member or through an invite link, and what is written in it is encrypted like in any other group. What was written in such a group while it was public was not encrypted, and it does not become encrypted after the fact: until it is deleted from our servers on the date Section 5.3 gives for all older messages, it sits there in readable form.

The one conversation that is not encrypted is your conversation with our support team, and the app says so in it: Section 5.7.

5.3 Keys, and how long a message stays with us

Keys are generated on your device and are unique to you. Your public key reaches us — it has to, so that other people can encrypt for you. Your private key reaches us in one form only: wrapped in a key derived from your recovery code, so that a new device of yours can get your key back with that code. The recovery code itself never reaches us, is shown to you once, and is not recoverable from anything we hold; without it the wrapped blob is a block of noise to us.

What that adds up to is this: we cannot decrypt your private messages on request, under subpoena, or by our own decision — not because we promise not to, but because the one thing that would make it possible is the one thing we do not have. Reading another person's private conversation is impossible for the same reason: it is encrypted for its participants' devices only.

We say it this precisely rather than "your keys never reach us", which is the shorter sentence and the false one.

Our servers pass messages on; they do not keep your history. A message and its attachments reach us encrypted, and we hold them only until every device that has to receive them has confirmed that it stored them: each signed-in device of every recipient, and your own other devices as well. The application downloads a message's photos, files and voice notes as soon as the message arrives, so that confirmation covers them too. Then we delete the content — the encrypted text, its keys and the attachment files. A device that does not come for a message is not waited for indefinitely: thirty (30) days after a message was sent, its content is deleted whether every device has received it or not, and a device that comes back later does not get it. Thirty days is a ceiling: our servers do not accept a longer period, only a shorter one.

Some things make a message wait longer than it takes to arrive, up to that ceiling, and they are worth knowing: a recipient whose device is switched off or offline; a device that runs a version of the application released before this model, which never confirms what it stored; and a recipient who signed out of every device within the last thirty days, for whom a message waits as it would for an offline phone, so that it is there when they sign back in. A device nobody has opened for thirty days stops being waited for.

What outlives the content is a record without it: who sent the message, to which conversation, when, what kind of message it was, which message it replied to or which conversation it was forwarded from, whether it was edited or deleted, and the reactions to it. That record is what lets a device that was offline catch up in the right order, and it is deleted as well once the message is thirty days old. Section 5.5 lists the little that stays longer.

Messages sent before this model took effect (6 October 2026) stay on our servers as they were stored — as ciphertext, or in readable form for groups that used to be public (Section 5.2) — so that current versions of the application can download them to your devices. Thirty (30) days after the model took effect — on 5 November 2026 — they are deleted from our servers, content and record alike, including any Saved messages that older versions of the application had kept there.

Deleting a message is "delete for everyone", and it is the only kind of deletion the current application offers. Its text leaves our servers at once, its files within thirty (30) days, and the deletion reaches every device of every participant that is still receiving that conversation. Once the record of a message is gone, our servers no longer know who wrote it, and deleting it for everyone works only where that does not need proving: a group's owner or administrator can still remove it, and nobody else can, its author included. Leaving a group or archiving a conversation is not deletion and erases nothing.

5.4 What this costs you, stated plainly

Because we cannot read your messages and do not keep them, we also cannot restore them:

• your history lives only on your devices. We make no backup of it, in our storage or anyone else's, and the application marks its history and its media as excluded from the system's own backups, on Apple platforms and on Android alike;
• history reaches a new device only from another device of yours that has it, by a transfer you confirm on both (Section 5.12). Your recovery code restores your key, so a new device can read the messages that arrive from then on — it does not bring back history. Lose every device that holds your history and the history is gone, with the code or without it, including for us;
• a push notification tells you a message arrived and nothing more — the text is not in it, and we do not send it;
• search runs on your device, over what your device holds.

5.5 What we can see

Encryption protects content, not the fact of communication. To deliver messages we process metadata: your account identifier, the identifiers of chats you belong to, when a message was sent and its size, and the content-free record of each message that Section 5.3 describes, for thirty days. Two traces of a conversation stay as long as the conversation does: how far each participant has read, and which message numbers are pinned in it — the number, not the message.

Calls add a second kind, and it is the one worth naming separately, because it is written down rather than merely passed through: the call record described in Section 1 — both participants, the times, the duration, audio or video, how it ended, the caller's region, direct or relayed. A message you delete goes; the row about a call you made stays, because it is equally the other person's call log. Encryption does nothing for it, and nothing in this Policy claims otherwise.

Access to production systems is limited to the people who need it to run the Services. For conversations that access reaches the metadata above and nothing else — there is no path to content for anyone, ourselves included. The exception is the one Section 5.2 names: what was written in a group while it was public, until the date on which all older messages are deleted.

5.6 Reports and moderation

A report could only ever be filed about a public message, group or channel, and none of those exist any more. A private conversation cannot be reported, and the reason is not policy but arithmetic: it is encrypted, we cannot read it, and a report we could never act on would be a promise of a review that will not happen. What you can always do is leave a group and block the person.

A report filed while public conversations existed reached us with the address of the reported chat, the number of the reported message, the reason picked and an optional comment. We keep it until it is reviewed and for a period afterwards, so that repeat reports about the same object can be seen as a pattern.

Our staff can place a visible warning on a group (for example, "scam"), close a group, or suspend an account — on what they can establish without the content: what someone chooses to show us when they write to us, or the automatic limits in Section 6 of the Terms. They cannot open a conversation to look, and no combination of reports unlocks that ability.

A blue verification badge on an account or a group means that we checked that it is who it says it is. It is granted by a person, by hand, and never automatically.

5.7 Conversations with support

Your conversation with our support is not end-to-end encrypted, and we say so in the conversation itself. Support has to read your question in order to answer it. Those conversations, including the messages in them and the rating you leave, are readable by the operator handling them and by the owner of the Company, and are retained so that a later question can be understood in context.

And the first thing that reads your question is not a person at all. Unless we have switched the assistant off, the text you send goes to Google's Gemini and the first answer comes back from there — Section 3.7 sets out exactly what is sent, what is kept and for how long. So the list of readers is not closed at the operator and the owner: a third party's model is on it, and the question itself leaves our infrastructure to reach it. Nothing else you write in the Application does that: messages to other people go to their recipients and to nobody else, as ciphertext we cannot open.

Do not send passwords, recovery codes or payment card details to support. We never ask for them, and no support task requires them.

5.8 Government and law-enforcement requests

We respond only to requests that are legally valid and properly served. What we can produce is what we hold: the account's username and display name, the identifier issued by the sign-in provider, when the account was created, when it last connected, its devices, the identifiers of conversations it takes part in, the content-free records of the messages it sent in the last thirty days (Section 5.3), and the call records described in Section 1 — who called whom, when, for how long and how it ended. There is no phone number to produce — we never collect one. The content of messages, their attachments and their keys we cannot produce either: what we hold of them is ciphertext, and only for the periods in Section 5.3, and a request for it returns nothing we can read. The one exception, until the date in Section 5.3, is what was written in a group while it was public, which is not encrypted.

We will not build a way around our own encryption, at anyone's request, commercial or governmental. There is no copy of your key that we can open — the one we hold is locked by your recovery code (Section 5.3) — no master key, no hidden extra recipient, and no mechanism by which one could be added to messages already sent. If a jurisdiction requires us to weaken this design as a condition of operating there, we will stop offering the Services in that jurisdiction rather than comply, and we will say so here and in the App before it takes effect — a change of this kind changes what oChat is, and we do not reserve the right to make it silently.

We notify the user whose data is requested before disclosing anything, unless prohibited by law or where someone's life is at immediate risk. When a prohibition expires, we notify then.

5.9 Breaches

Where a personal-data breach is likely to result in a risk to your rights, we notify the competent supervisory authority without undue delay and, where feasible, within 72 hours, as GDPR Art. 33 and the Serbian LPDP require. Where the risk to you is high, we notify you directly.

A breach of our servers exposes ciphertext rather than the content of your messages — and, once the messages from before this model are gone (Section 5.3), only the ciphertext of messages less than thirty days old — the situation GDPR Art. 34(3)(a) describes, and the main reason this design is worth its costs. It is not a promise that nothing can go wrong: the metadata in Section 5.5 is real data, and its exposure would be real. What was written in a group while it was public is not ciphertext, and until the date in Section 5.3 a breach would expose it as it stands.

5.10 On your own device

The copy of your conversations that lives on your device is stored decrypted. End-to-end encryption covers the journey and our servers: what we hold is ciphertext, and Section 5.3 explains why we cannot open it. The local database the application reads to draw your chat list is a different thing — it holds your messages in the clear, on Android and on iOS and macOS alike. We write that here rather than let "encrypted, always" be read as a statement about your phone, because it is not one.

It is a deliberate trade rather than an oversight. The key would have to sit on the same device as the database, so storing ciphertext there would protect against almost nothing while making the application unwrap a message on every scroll. What guards that database is where it sits: the application's own storage area, which other applications on the device cannot read.

What follows from it is practical. Someone holding your unlocked device can read your messages in the application, and so can anyone able to extract that application's storage from the device.

That database is now the only place your history exists, and the application, starting with the versions released after 7 October 2026, treats it accordingly. Signing out — on purpose, or because a session ended — does not erase it: the history stays on the device, kept for that account, and is there again when you sign back in with the same account. Another account signed in on the same device sees only its own history and can neither read nor export yours. Deleting your account erases that account's history on the device you delete it from, and deleting the application erases everything it kept. Earlier versions of the application erase the history on the device when you sign out. So a device you hand on should have the application deleted, not merely be signed out. Saved messages live here and only here: versions of the application released after 7 October 2026 send neither their text nor their files to our servers.

5.11 Who else can see who is in a conversation

In a group, the list of members is open to every member: display names, usernames, avatars, and the online or last-seen line where the person's own privacy setting permits it. That is what a group is, and joining one is agreeing to it.

Our servers hold that list too, with each member's role and who added whom — they need it to know where a message has to go — together with a group's title, its avatar, its settings and its invite links. None of that is encrypted, and it stays as long as the group does.

5.12 Moving your history to a new device

Since your history lives on your devices, it reaches a new one only from another device of yours that has it — an iPhone, a Mac or an Android phone signed in to the same account. The new device asks; the old one shows the request together with the new device's platform, its name, its country and the date it first signed in, and the transfer goes ahead only when you type, on the old device, the six-digit code the new one displays. That code is not sent to us, and it is built so that a substituted key would change it: it is how the two devices make sure they are talking to each other and not to someone in between, ourselves included.

The old device then packs your history — your conversations, including Saved messages and conversations you have left, with their photos, files and voice notes — into an archive encrypted with a key made for that one transfer, and hands that key, together with your account key, to the new device in a form only the new device can open. The archive travels through our storage in encrypted parts that we cannot read. It is deleted once the new device confirms the import, when either device cancels, or when the transfer expires: after twenty-four (24) hours without activity, and in any case seven (7) days after it was requested. What we keep of a finished transfer — its state, its size, the two devices' names, platforms and countries — is deleted a day later.

Because a transfer hands over your whole history and your key, confirm one only when you are holding the new device yourself. Someone who has taken over your Apple or Google account, or your email address and password, can ask for a transfer, but cannot complete one without the code shown on their device being typed into yours.

5.13 History for someone you add to a group

If a group's settings let new members see earlier messages, adding someone to it makes your device send them recent history: the last hundred (100) messages of the last fourteen (14) days that your device holds, with thumbnails and with files of up to sixteen (16) MiB each, two hundred and fifty-six (256) MiB in all, encrypted for the keys of the people you added and for nobody else. It passes through our storage and is deleted once every device of the new member has downloaded it, or seven (7) days after it was sent, whichever comes first. Only the person who added a member can send them history; someone who joins through an invite link gets none.

The new member's application checks that each message in that history matches the record our servers still hold — the sender and the time — and shows that the history was sent by the member who added them. Where the server no longer has the content to compare against, the text and the files are that member's word.

5.14 What our servers keep regardless

"We do not keep your messages" is true; "we keep nothing" would not be. Among what stays on our servers, independently of the thirty-day rule above, is the following:

• your account and profile — the sign-in identifier, display name, username, bio, avatar, emoji status and privacy settings — and your decisions about who may write to you;
• your public key, and the copy of your private key locked by your recovery code (Section 5.3);
• your devices and sessions and their push tokens (Section 1);
• your list of conversations, with what you set on each — muted, pinned, archived — how far you have read and the time of the latest message, and your chat folders, with their names and the conversations in them;
• groups, as Section 5.11 describes, and the numbers of pinned messages;
• call records (Section 1);
• your conversations with support, in readable form (Section 5.7), and reports already filed (Section 5.6);
• subscriptions, purchases, your star balance and its transactions; if you use them, your profile, rooms and points in the drawing game, and the protection subscription with the devices registered to it and their traffic counters;
• technical logs and database backups, for the periods in Section 9.

6. Your Rights

Depending on your location, applicable data-protection law (such as the EU GDPR or the Serbian Law on Personal Data Protection) may grant you the following rights with respect to your personal data:

• the right of access — to obtain confirmation of whether we process your personal data and a copy of that data;
• the right to rectification — to have inaccurate or incomplete data corrected;
• the right to erasure ("right to be forgotten");
• the right to restriction of processing;
• the right to data portability — to receive your account data in a structured, machine-readable format. The content of your messages is not part of it and cannot be: we do not keep your history, and what passes through us is ciphertext we cannot open. Your history is on your devices, where the keys are;
• the right to object to processing;
• the right to withdraw consent at any time, where processing is based on consent;
• the right to lodge a complaint with a supervisory authority. In Serbia, the supervisory authority is the Commissioner for Information of Public Importance and Personal Data Protection (poverenik.rs). EU residents may contact the data-protection authority in their country of residence.

To exercise any of these rights, contact us at the email address in Section 11. We respond within thirty (30) days.

How we verify who you are. We ask you to send the request from the account itself, using the in-app support option: being signed in to the account is the proof. If you can no longer sign in, write to us from the Apple or Google account, or from the email address, you sign in to oChat with, and we will check that it matches. We do not ask for a copy of an identity document, and we will not act on a request we cannot tie to the account — the alternative is a procedure by which someone else can obtain or erase your data by writing us a convincing email.

What erasure can and cannot reach. Deleting your account empties your profile and removes the records that belong to you alone. It does not remove the messages you sent: those stay in the chats of the people you sent them to — on their devices, because a message you sent is half of their conversation and taking it out would rewrite their history for them; on our servers only for as long as any message stays there (Section 5.3). Section 9 sets out what is deleted, what is emptied and what stays. Even where we decided otherwise, the copies on their devices are decryptable only by their keys and we could not reach them — the same property that keeps us out of your conversations, seen from the other side. If you need a message gone from someone else's chat, delete the message itself before you delete the account, or ask them.

You can delete your account from within the Application at any time; see Section 9 for what deletion removes and when.

7. Children's Privacy

You must be at least 16 years old to use oChat. The Application is not intended for anyone younger, and we do not knowingly collect personal information from children. If we learn that an account belongs to someone under 16, we delete it and the data associated with it.

Sixteen rather than thirteen is a deliberate choice. GDPR Art. 8 lets each EU member state set the digital-consent age anywhere between 13 and 16, and a lower figure would oblige us to obtain and verify parental consent in the countries that set a higher one. We have no mechanism for that, and a rule we cannot enforce is worse than a stricter rule we can.

8. International Data Transfers

Your data may be transferred to and processed in countries other than your country of residence. Where we are the party arranging the transfer, this is what it rests on:

• Our servers and databases run in the European Union (Amsterdam, Netherlands), as does the object storage through which encrypted attachments and history transfers pass (Western Europe). For EU residents this is not a transfer at all.
• Providers incorporated in the United States — Cloudflare, Railway, Google (Firebase Authentication, Cloud Messaging, Analytics, Crashlytics, Google Play and the Gemini API), Apple, Amplitude, Sentry and Polar — process data on our behalf under the European Commission's Standard Contractual Clauses, together with the supplementary measures each of them publishes.
• The text of a support question leaves our infrastructure for Google's Gemini API in order to be answered (Section 3.7), under the same Standard Contractual Clauses as the providers above. We give it its own line rather than folding it into theirs, because it is different in kind: they receive identifiers, metadata and diagnostics, and this one receives something you wrote in your own words.
• Operational alerts go to Telegram (Section 3.8). This is a transfer we make ourselves, and it goes to a messenger rather than to a processor we contracted for it: Telegram is not established in the European Union, and no adequacy decision covers this leg. What travels is an account identifier and a description of an event — never message content — and it stays in that chat until we delete it there.
• The reverse proxy for users in the Russian Federation (Section 3.3) is not covered by an adequacy decision either. It carries encrypted traffic and terminates TLS in Russia. What passes through it is the content of conversations as ciphertext we ourselves cannot read, except what was written in groups while they were public, until the date in Section 5.3; your conversations with support, which are not end-to-end encrypted (Section 5.7); and the connection metadata any proxy sees: source address, destination host, timing and size.

9. Data Retention

• Messages and attachments are retained as ciphertext only until every device they are addressed to has stored them, and for thirty (30) days at most; the content-free record of a message is deleted when it is thirty days old (Section 5.3). A message you delete disappears from the app immediately, its text leaves our servers at once and its files within thirty (30) days.
• Messages sent before this model took effect, including what was written in groups while they were public and Saved messages kept by older versions of the application, are deleted from our servers thirty (30) days after it took effect — on 5 November 2026 — content and record alike (Section 5.3).
• History transfers between your devices are deleted from our storage when the new device confirms the import, when the transfer is cancelled, or when it expires — after twenty-four (24) hours without activity and at most seven (7) days after the request; the record of a finished transfer, a day after it finished (Section 5.12). History sent to a member you add to a group is deleted once all of their devices have downloaded it, or seven (7) days after it was sent (Section 5.13).
• Backups are counted in copies, not in days: we keep the three most recent successful daily copies of each database and delete the rest. Two things follow from that, and neither is what "three days" would suggest. The count starts only once the data is actually gone from the database — the content of a message leaves it once delivered, and at most on the dates in Section 5.3, and only the copies taken after that are free of it. And if the nightly job fails, the copies it should have replaced stay: copies older than thirty (30) days are deleted, but never the newest copy of a database, so a job that stops for longer than that leaves one stale copy rather than none, until a new one replaces it. In the ordinary case content stops appearing in backups about three days after it leaves the database. That is how it usually goes, not a guarantee we are in a position to give.
• Attachments uploaded but never sent are removed after twenty-four (24) hours.
• Devices that stop connecting keep their record until you revoke the session or delete the account. A refresh token expires on its own after ninety (90) days and stops working then.
• Account deletion. When you ask us to delete your account, the purge runs thirty (30) days later. The delay is deliberate: deletion is irreversible, an accidental tap is common, and someone who takes over an account deletes it first to cover their traces. Deleted outright are the records that belong to you alone: your devices and sessions, your push tokens, your list of conversations and the folders you sorted them into, the contacts we hold for you, your entry in the username directory, your reactions and read receipts, the list of messages you hid, and your subscription, purchase and entitlement records. Your copies of the content keys go with them, which is what leaves your side of a conversation unreadable afterwards by anyone, ourselves included. On the device you delete the account from, the application also erases that account's history (Section 5.10). Your profile row is emptied rather than removed: display name, username, bio, avatar, last-seen and the key material your recovery code unwraps are all stripped. The row itself has to stay — messages in other people's conversations point at it, and deleting it would turn their sender into an identifier with nothing behind it. Your sign-in record in Firebase Authentication is deleted by the purge as well: the purge first removes the link from that record to your oChat account and then deletes the record itself — with your email address and, if you signed in with email, your password — from our Firebase project's list of users. If Firebase cannot be reached at that moment, the purge does not give up on it: it tries again until the deletion goes through. The one exception: if before the purge you signed in again with the same Apple ID, Google account or email address and that created a new oChat account, the record now belongs to that new account, and it is kept.Deleting the account does not cancel your subscription. The subscription belongs to the store account that bought it, we delete only our own record of it, and the charges go on until you cancel it in that store — Section 13 of the Terms says where.
• Account deletion: what stays, and why. The messages and attachments you sent are not deleted from the devices of the people you sent them to; on our servers they stay only as long as any message does (Section 5.3). A message you sent is sitting in someone else's chat, and that conversation is as much theirs as yours; removing it would take half of their history away on your decision alone. The same reasoning keeps the record of your calls (the "missed call" on the other side is theirs), messages pinned in a group, the groups you created — they have members, and closing them would be deleting what belongs to those people — and invitation links others are still using, of which we clear only the names you gave them. Your membership in each conversation is marked as left rather than erased. A report you filed about someone else stays too: it is a record of their conduct, not yours. So does your conversation with support, with the copy of your username in it replaced by the same marker. After the purge all of this points at a profile with nothing left in it — no name, no avatar, no route back to you — but it is still there, and you should decide knowing that. If you want something gone from everyone's copy, delete the message itself before you delete the account: that is a different action, and it does reach the other side, on the terms in the first item of this section.
• Suspended accounts. Where an account is suspended following a report, we keep the account record and the report for one hundred and eighty (180) days after the suspension, so that an appeal can be examined and so that the same account cannot simply be recreated. Where the suspension follows a report about a private conversation, the record holds no message content — we do not have it. Where it followed a report about a public group or channel, filed while those existed, it holds the reported message, because a report we cannot look at is a report we cannot act on.
• Call records are kept for as long as the conversation they belong to, and they survive the deletion of your account. That is deliberate: the row is half of the other participant's call log, and erasing it would take a "missed call" out of their history on your say-so. After your account is purged, your side of the record points at an account row with nothing left in it.
• The support assistant's own log of questions and answers (Section 3.7) is erased after fifteen (15) days. The support conversation itself stays with us on the terms above.
• Technical logs — connection times, addresses, error traces — are kept for thirty (30) days. The figure is our hosting provider's retention, not an aspiration: after thirty days the records no longer exist to be produced.
• Operational alerts in Telegram (Section 3.8) are the exception to everything above. They are messages in a chat, not rows in our databases, and nothing expires them: they stay there until someone deletes them by hand.
• Payment and accounting records are retained for ten (10) years, as required by Serbian accounting law.

10. Changes to This Privacy Policy

We may update this Privacy Policy from time to time. The new version becomes effective upon its publication within the Application or on our website. We recommend that you review this Policy periodically. Your continued use of the Application after changes are published constitutes your acceptance of the updated Policy. Where a change materially affects how we handle message content, we will announce it in the Application rather than only on this page.

11. Contact Information

If you have questions about this Privacy Policy, or wish to exercise any of the rights described in Section 6, please contact us:

Data Controller: Vitalii Sosin PR Beograd

Legal form: Sole proprietor (preduzetnik)

Registered address: Kneza Miloša 15, 11167 Beograd (Vračar), Republic of Serbia

Registration number (Matični broj): 68444683

Tax ID (PIB): 115539784

Email: [email protected]

Website: ochat.club

Политика конфиденциальности

Последнее обновление: 10 октября 2026 г.

Настоящая Политика конфиденциальности описывает, как Vitalii Sosin PR Beograd («Компания», «мы», «нас» или «наш») собирает, использует и защищает вашу информацию при использовании вами oChat — приложения oChat для iOS, macOS и Android («Приложение» или «Сервисы»). Используя Приложение, вы подтверждаете, что прочитали и поняли настоящую Политику.

Три сборки — это одно приложение, и данные они обрабатывают одни и те же и ради одного и того же. Там, где Android отличается от iOS и macOS — способом входа, службой, которая доставляет уведомления или принимает оплату, встроенным SDK, — отличие названо в том месте, где оно действует, а не оставлено вам на догадку.

Оператором персональных данных является Vitalii Sosin PR Beograd, индивидуальный предприниматель (preduzetnik), зарегистрированный в Республике Сербия. Полные регистрационные сведения приведены в Разделе 11.

Мы стремимся обрабатывать персональные данные в соответствии с Общим регламентом ЕС по защите данных (GDPR), где он применим, сербским Законом о защите персональных данных («Zakon o zaštiti podataka o ličnosti») и иным применимым законодательством.

1. Какую информацию мы собираем

Информация, которую предоставляете вы

• Личность при входе. Вы входите посредством Firebase Authentication. Какие способы предлагаются, зависит от платформы: на iOS и macOS — Apple, Google или адрес электронной почты и пароль, на Android — Google или адрес электронной почты и пароль, входа через Apple там нет. К нам попадает идентификатор учётной записи, который выдаёт этот провайдер, и отображаемое имя, если вы разрешили его передать. Если вы входите по почте, пароль хранит Firebase Authentication, а не мы. По пути туда он проходит через наши серверы — приложение отправляет запросы регистрации, входа и сброса пароля нашим серверам, а они передают их в Firebase, — и мы его не храним. Номер телефона мы не спрашиваем и не храним, пароль от Apple или Google к нам не попадает — хотя там, где действует российское направление трафика, страница, в которую вы этот пароль вводите, доходит до вас через наш домен; полностью это разобрано в Разделе 3.3. Если вы пользуетесь функцией Apple «Скрыть e-mail», настоящего адреса мы тоже не видим.
• Ваш адрес электронной почты. Провайдер входа передаёт адрес приложению, и приложение показывает его вам в карточке вашей же учётной записи. При входе через Apple или Google на наши серверы он не уходит; при входе по почте уходит — об этом в конце пункта. В любом случае в нашей базе нет поля, куда его положить. Это уже́, чем «мы его не видим», и разницу стоит назвать: вход идёт через Firebase Authentication в проекте, который принадлежит нам, — то есть ваш адрес лежит в списке пользователей этого проекта, а список мы как его владелец открываем и выгружаем. Чего адрес не касается, так это той базы, где живут ваш профиль, ваши чаты и ваши сообщения. При входе по почте адрес попадает на наши серверы, потому что вы вводите его при регистрации, входе и сбросе пароля, а мы отправляем на него письма с шестизначным кодом — чтобы подтвердить адрес при регистрации и чтобы сбросить забытый пароль. Пока такой код действует, наши серверы хранят адрес рядом с ним, а сам код — только в виде хеша с секретным ключом; и то и другое удаляется через десять (10) минут или раньше, как только код использован.
• Профиль. Отображаемое имя, юзернейм, краткое описание и аватар — если вы их задали.
• Содержимое сообщений и вложения. Текст ваших сообщений и отправленные файлы, изображения и голосовые сообщения проходят через наши серверы зашифрованными вашим устройством, и храним мы их только до тех пор, пока их не получат все устройства, которым они адресованы, и никогда не дольше тридцати (30) дней. История вашей переписки хранится на ваших устройствах, а не у нас, а «Избранное» в текущей версии приложения на наши серверы не попадает вовсе. См. Раздел 5 — это та часть Политики, которую стоит прочитать внимательнее всего.
• Переписка с поддержкой и жалобы. То, что вы пишете нашей поддержке, — в открытом виде (Раздел 5.7). Жалобы на сообщение, группу или канал можно было подать, пока существовали публичные группы и каналы; их больше нет, а уже поданная жалоба хранится так, как сказано в Разделе 9.

Информация, собираемая автоматически

• Идентификатор устройства, модель, версия операционной системы, версия приложения, язык и платформа. Идентификатор приложение заводит себе само — случайное значение в защищённом хранилище устройства: Keychain на iOS и macOS, хранилище с ключом из Keystore на Android. Это не серийный номер и не рекламный идентификатор; на Android разрешение на рекламный идентификатор вырезано из собранного манифеста, так что прочитать его приложение не смогло бы, даже если бы какая-то библиотека попросила.
• Имя вашего устройства — то, которым устройство само себя называет, — чтобы в списке ваших сессий стояло «Pixel 9 Pro», а не строка из идентификаторов. Стоит знать заранее: устройство часто называют своим именем, и устройство «Телефон Анны» сообщает нам имя, которого мы не спрашивали. Переименовать устройство можно в системных настройках; новое имя заменит прежнее при следующем обращении приложения к серверу.
• Токен push-уведомлений — чтобы уведомления доходили до вашего устройства: служба Apple Push Notification на iOS и macOS, Firebase Cloud Messaging на Android. На Android тот же токен записывается ещё и как токен звонка: система доставки Google сама решает, насколько срочно будить устройство из режима энергосбережения, и приглашение в звонок, пришедшее обычным приоритетом, приходит минутами позже.
• Данные подключения: IP-адрес в момент подключения, время подключения, последней активности и статуса «был(а) в сети».
• Приблизительное местоположение, выведенное из этого IP-адреса. Разрешения на геопозицию приложение не просит и не имеет ни на одной из платформ — обращения к GPS в нём нет вовсе. Но IP-адрес подразумевает место, и этим пользуются двое: наши серверы читают код страны, который приписывает запросу Cloudflare, чтобы решить, отдавать ли вас российскому зеркалу (Раздел 3.3); а продуктовая аналитика выводит из того же адреса страну и регион. Город, оператор связи и сам адрес там отключены. Страна и регион — нет, и вместо того чтобы доказывать, что регион — это не местоположение, мы называем вещи своими именами: это приблизительное местоположение, оно собирается во всех сборках и всё время, пока вы пользуетесь Приложением.
• Запись о каждом звонке. Звонок заводит строку, которая переживает сам разговор: кто звонил и кому, когда звонок создан, принят и завершён, сколько длился разговор, был он голосовым или с видео, чем кончился (положили трубку, отклонили, пропустили, занято, не собрался), из какого региона подключился звонивший и пошло ли медиа напрямую или через ретранслятор. Чего в этой строке нет — так это самого разговора. Звук и видео идут между двумя устройствами зашифрованными и к нам не попадают, а то, из чего звонок собирается, — оффер, сетевые кандидаты, отпечатки ключей — запечатывается на вашем устройстве для устройства собеседника: мы перекладываем это, не умея ни прочитать, ни подделать, и оно исчезает вместе со звонком. Из этой строки и собираются ваш журнал звонков и пузырь звонка в переписке.
• Технические журналы и диагностика сбоев и ошибок.
• Состояние подписки и идентификаторы покупок, получаемые от Apple, от Google Play или от нашего платёжного партнёра.

Чего мы не собираем

В Приложении нет рекламных SDK и ничего, что составляло бы ваш профиль для маркетинга. Рекламный идентификатор оно не читает ни на одной платформе: на iOS и macOS не запрашивает разрешение App Tracking Transparency и не обращается к IDFA, на Android разрешения на рекламный идентификатор вырезаны из манифеста. Ничто из собираемого не связывается с данными из приложений и сайтов других компаний.

А есть в нём продуктовая аналитика и сбор отчётов о сбоях — Amplitude, Sentry, Firebase Analytics и Firebase Crashlytics, все перечислены в Разделе 3.5. Этот сбор не является необязательным. Переключатель для него когда-то был в настройках приложения; его убрали — и мы предпочитаем сказать об этом здесь, а не оставить стоять прежнюю формулировку. Диагностика запускается вместе с приложением — раньше экрана входа, на котором стоит ссылка на эту Политику; поэтому ссылка стоит именно там, а этот абзац — именно здесь. Ограничивает сбор не переключатель, а то, что этим службам дают: идентификатор учётной записи, данные об устройстве и версии, имена событий — и никогда содержимое сообщения. Что достаётся каждой из них, сказано в Разделе 3.5.

Сайт — отдельная история, и прежняя редакция этого абзаца описывала его скромнее, чем он есть. Cookie он не устанавливает, а шрифты и собственные изображения отдаёт со своего домена. Но скрипты других компаний он загружает, и часть его страниц хранит данные в вашем браузере:

• Каждая страница несёт Cloudflare Web Analytics: мы включили её для сайта, и Cloudflare сам встраивает её в каждую страницу, когда отдаёт её. Это скрипт с static.cloudflareinsights.com, который сообщает адрес страницы, страницу, с которой вы пришли, и то, как быстро она загрузилась. Cookie он не ставит и в браузере ничего не хранит. Подробнее — в Разделе 3.2.
• Страницы, на которых можно войти, — кабинет /app/, подписка «Защита» /vpn/ и страница поддержки /donate/ — загружают библиотеку Firebase Authentication от Google с www.gstatic.com сразу при открытии, войдёте вы или нет. Нажатие кнопки входа загружает ещё скрипт с apis.google.com и кадр с auth.ochat.club и открывает окно, которое ведёт на страницу входа Google или Apple, — та хранит собственные cookie на собственном домене. Подробнее — в Разделе 3.1.
• Публичная доска заявок /feedback/ показывает приложенные к заявкам фото и видео прямо из нашего хранилища Cloudflare R2 или из его зеркала на нашем домене, а файл, который прикладываете вы, браузер загружает туда напрямую.

Что остаётся в браузере (в localStorage, если не сказано иное): на главной, на юридических страницах и на страницах, которые передают ссылку в приложение, — выбранные вами тема и язык. На страницах со входом — случайный идентификатор этого браузера, который появляется при первом входе на одной из них; а после входа — токены вашей сессии oChat и собственная запись Firebase об учётной записи, через которую вы вошли: её идентификатор, ваш адрес почты, имя и адрес фотографии, которые передаёт провайдер, и собственные токены Firebase. Эту запись Firebase держит в IndexedDB браузера и там же, вошли вы или нет, хранит даты, когда работала его библиотека, и её версию. Выход на этих страницах стирает токены сессии и запись Firebase; идентификатор браузера остаётся — чтобы тот же браузер не считался новым устройством при каждом входе. Страницы /premium/, /android/ и /feedback/ в браузере не хранят ничего.

2. Как мы используем вашу информацию

• Для работы Сервисов: доставки ваших сообщений выбранным вами получателям и другим вашим устройствам и отображения статусов доставки и прочтения.
• Чтобы по вашей просьбе перенести историю с одного вашего устройства на другое, а участнику, которого вы добавили в группу, — передать недавнюю историю этой группы (Разделы 5.12 и 5.13).
• Для входа и поддержания сессии на всех ваших устройствах.
• Для отправки push-уведомлений о новых сообщениях и входящих звонках.
• Чтобы собрать звонок, который вы делаете, и хранить запись о нём — она и есть ваш журнал звонков и журнал вашего собеседника.
• Для предотвращения, выявления и расследования злоупотреблений, спама, мошенничества и нарушений наших Условий, а также для их применения.
• Для обработки подписок, покупок и возвратов.
• Для оказания поддержки и ответов на ваши обращения.
• Для обеспечения надёжности и безопасности Сервисов и диагностики сбоев.
• Для соблюдения требований законодательства.

Мы не используем содержимое сообщений для рекламы, не продаём персональные данные и не обучаем на ваших сообщениях модели машинного обучения. Единственное, что мы отдаём модели, — это вопрос, который вы пишете в поддержку, и только затем, чтобы на него ответить: что именно уходит, кому и что остаётся потом, сказано в Разделе 3.7.

3. Поставщики услуг, обрабатывающие данные по нашему поручению

Мы используем перечисленных ниже поставщиков. Каждый обрабатывает данные по нашим инструкциям и для указанной цели, и у каждого есть собственная политика конфиденциальности.

3.1 Аутентификация

Firebase Authentication (Google) — принимает ваш вход и выдаёт токен, который мы обмениваем на сессию oChat: на iOS и macOS — через Apple, Google или почту и пароль, на Android — через Google или почту и пароль. В рамках этой проверки Google получает базовые данные об устройстве и сети, а также ваш адрес электронной почты — потому что проверяется учётная запись, принадлежащая ему же. При входе по почте он же хранит пароль от этой учётной записи, а создают и обновляют её в Firebase от вашего имени наши серверы. Номер телефона в этом не участвует.

Cloudflare Email Sending — отправляет письма с шестизначными кодами для подтверждения регистрации по почте и для сброса пароля, с адреса [email protected]. Он получает ваш адрес электронной почты и текст письма, в котором есть код.

На этом сайте кабинет, подписка «Защита» и страница поддержки входят через тот же проект Firebase — с Apple или Google. Библиотека приходит с серверов Google, а кадр и окно, через которые идёт вход, отдаются с auth.ochat.club — нашего поддомена, который указывает на Firebase Hosting от Google: то, что там работает, — код Google, и отдаёт его Google. Что сайт хранит в браузере после входа, сказано в конце Раздела 1.

3.2 Инфраструктура, хранение и доставка

Cloudflare — доставка контента, защита на границе сети и ограничение частоты запросов, а также объектное хранилище R2: там хранятся аватары, там ждут доставки вложения (Раздел 5.3) и через него проходят зашифрованные архивы переноса истории (Разделы 5.12 и 5.13). Railway — хостинг наших серверов приложений и баз данных, включая сервис помощника поддержки из Раздела 3.7.

Ещё Cloudflare размещает этот сайт и измеряет его: Cloudflare Web Analytics, включённая для сайта, встраивается Cloudflare в каждую страницу и сообщает адрес страницы, страницу, с которой вы пришли, и то, как быстро она загрузилась. Cookie она не ставит и в браузере ничего не хранит.

У звонков к Cloudflare есть второе дело: его серверы STUN и TURN — это то, чем два устройства находят путь друг к другу через свои сети. Когда прямого пути нет — а в изрядной части мобильных сетей его нет, — звук и видео идут через ретранслятор Cloudflare: значит, он несёт эти пакеты и видит оба адреса. Открыть их он не может: медиа зашифровано между устройствами, и ключи — их.

3.3 Обратный прокси для пользователей из Российской Федерации

Для пользователей, подключающихся из Российской Федерации, приложение может направлять трафик API и медиа через обратный прокси, размещённый в Российской Федерации. Этот прокси терминирует TLS-соединение с вашего устройства, видит ваш IP-адрес и метаданные подключения и передаёт трафик на те же серверы, что описаны выше. Собственных копий содержимого сообщений он не хранит.

В этом же регионе приложение направляет через наш поддомен и сами запросы входа — те, что устройство отправляет на серверы аутентификации Google: оттуда они доходят не всегда, и отказ этот молчаливый. Перенаправление сделано на обеих платформах — на iOS и macOS на уровне загрузки адресов, на Android внутри HTTP-клиента, — и список адресов, к которым оно применяется, закрытый и короткий: адреса провайдера входа, и ничего больше. Скажем прямо, что это значит, потому что значит оно ровно то же, что всегда значит прокси: эти соединения наш узел тоже терминирует, и обмен проходит через нашу инфраструктуру, прежде чем дойти до Google. В обмене едет токен, который провайдер выдал для вас, и токен, который он выдаёт в ответ.

На iOS и macOS в это перенаправление попадает и сама страница входа, и приукрашивать это мы не станем. Вход через Google там — это веб-страница, собственный экран согласия Google, тот самый, где вы набираете пароль Google и второй фактор. Там, где действует это перенаправление, приложение открывает эту страницу по адресу ru-google-auth.ochat.club — нашему поддомену, — а не по accounts.google.com. Это соединение наш узел тоже терминирует, то есть страница, в которую вы вводите пароль Google, доходит до вас через нашу инфраструктуру, и введённое возвращается тем же путём. Мы его не читаем, не храним и не пишем в журнал, а приложение пароля не получает вовсе — но это утверждение о нашем поведении, а не свойство самой конструкции, и это не одна и та же гарантия. У входа через Apple такой страницы нет вовсе: это системный лист, и в нём не перенаправляется ничего.

На Android перенаправлять нечего: учётная запись выбирается в системном листе Credential Manager, пароль не набирается ни в чём нашем, и эта сборка уводит на зеркало только машинные запросы к серверам провайдера. Всё сказанное про вход в этом разделе действует, пока включено российское направление трафика; вне его приложение ходит к провайдеру входа напрямую, и зеркала в этом пути нет совсем.

3.4 Уведомления и покупки

Apple (iOS и macOS) — служба Apple Push Notification доставляет уведомления на ваши устройства, а App Store Server API сообщает нам статус вашей подписки. Когда вы запрашиваете у Apple возврат, Apple может запросить у нас сведения об использовании этой покупки.

Google (Android) — Firebase Cloud Messaging доставляет на ваше устройство уведомления и приглашения в звонок, то есть Google передаётся токен, опознающий эту установку, и то уведомление, которое мы просим доставить. Google Play Billing продаёт подписки, приобретаемые внутри Android-приложения: платёжное средство и платёжные данные — забота Google, к нам они не попадают. К нам с вашего устройства приходит то, что Google Play отдаёт ему обратно: токен покупки, идентификатор продукта и имя пакета — чтобы подписку можно было сверить с Google и выдать право вашей учётной записи.

Polar Software, Inc. — продавец записи (merchant of record) для покупок вне магазинов приложений; Polar получает ваши платёжные данные и обрабатывает платёж и налоги.

3.5 Продуктовая аналитика и мониторинг ошибок

Amplitude (все сборки) — продуктовая аналитика: какие экраны открывают и какие действия доводят до конца, вместе с идентификатором учётной записи и базовыми данными об устройстве. Нужна затем, чтобы отличать возможность, которой не пользуются, от возможности, которая сломана. Содержимое сообщений, контакты и вложения туда не передаются. На iOS, macOS и Android она одинаково настроена не получать ни IP-адреса, ни города, ни оператора связи; страну и регион она при этом выводит — это и есть приблизительное местоположение, названное в Разделе 1. Один переключатель на платформах разный, и мы лучше назовём его, чем округлим: на Android выключен рекламный идентификатор устройства, а на iOS и macOS — идентификатор поставщика (IDFV), идентификатор установки от Apple, который рекламным не является. Выключать рекламный идентификатор на платформах Apple вообще не от чего: приложение не запрашивает App Tracking Transparency и не читает IDFA, как сказано в Разделе 1.

Sentry (все сборки) — отчёты о сбоях и диагностика ошибок: идентификатор пользователя, метаданные запроса, трассировки стека. Содержимое сообщений не передаётся. На Android это и есть сборщик падений.

Firebase Analytics (Google) (Android) — те же события под теми же именами во второй панели, вместе с идентификатором учётной записи и теми данными об устройстве, которые SDK Google собирает для себя. В сборке Android сбор выключен в манифесте и включается только тогда, когда конфигурация присылает приложению ключи аналитики. На iOS и macOS приложение не отправляет туда ничего: ни одного события и ни одного идентификатора, и описанные выше события уходят там только в Amplitude. Библиотека при этом в сборки Apple всё равно входит, и ничто в них не выключает то автоматическое измерение, которое SDK Google ведёт само, как только Firebase настроен. Поэтому здесь теперь названа платформа, а не «все сборки»: прежняя формулировка читалась так, будто на платформах Apple существует вторая копия наших событий. Её нет.

Firebase Crashlytics (Google) (iOS и macOS) — отчёты о падениях приложения, с той же целью и в тех же границах, что и Sentry. В сборке Android эта библиотека тоже присутствует, но сбор в её манифесте выключен и ничто его не включает — то есть на Android падения уходят только в Sentry. Мы упоминаем библиотеку, которая ничего не собирает, потому что в пакете она всё равно лежит, а вы вправе знать, что в пакете.

Имена событий и ключи свойств — закрытый список, произвольное поле приложение отправить не может, а каждое значение перед уходом с устройства проходит через очистку, которая заменяет всё похожее на адрес почты, номер телефона, токен или код восстановления. Ни одна из этих служб не используется для рекламы и ни одна не получает того, что вы пишете.

3.6 Демо-режим

На Android приложение умеет показывать демо: выдуманную учётную запись с выдуманной перепиской, куда ведёт кнопка на экране входа. Он нужен потому, что вход там возможен только через учётную запись Google, а человек, который приложение проверяет, — в Google Play или вы сами, до того как решите входить, — должен иметь возможность посмотреть, что это, не заводя её. В сборках для iOS и macOS демо пока нет. Кнопка появляется только тогда, когда демо включено у нас на сервере, и демо заменяет собой всё приложение целиком: ничто из сделанного в нём не затрагивает настоящую учётную запись, потому что в демо у приложения нет ни сессии, ни ключей.

Что здесь стоит объявить отдельно: фотографии и портреты для демо загружаются с двух сторонних сервисов изображений — picsum.photos и i.pravatar.cc. Запросы идут с вашего устройства, поэтому эти два сервиса видят ваш IP-адрес и сам факт запроса — как любой сайт. Данных учётной записи они не получают, потому что в демо её нет. Вне демо-режима приложение к ним не обращается никогда.

3.7 Помощник, который отвечает в поддержке первым

Google (Gemini) — когда вы пишете в поддержку, первым отвечает не человек, а помощник на большой языковой модели. Приложение говорит об этом над первым же вашим сообщением, а Политика договаривает остальное: чтобы получить этот ответ, текст вашего вопроса уходит в Gemini API компании Google и обрабатывается на её собственной инфраструктуре. Google — компания из США, и регион обработки мы в запросе не задаём, так что считайте, что адресат находится за пределами Европейского союза (Раздел 8). Модели, которыми это делается сегодня, — gemini-2.5-flash для ответа и gemini-embedding-001 для поиска нужной статьи в нашей базе знаний.

В Google уходит написанный вами текст и больше ничего, что указывало бы на вас: ни идентификатора учётной записи, ни юзернейма, ни остальной переписки. Сервис помощника ведёт свой журнал вопросов и ответов, чтобы мы могли отличать полезный ответ от плохого; идентификатора учётной записи в этом журнале тоже нет, и он стирается через пятнадцать (15) дней. Связь «ответ — человек, который спросил» остаётся у нас, в нашей базе, вместе с самой перепиской поддержки.

Мы просим Google сделать с этим текстом одно: ответить на вопрос. Что ему позволено делать с текстом сверх этого, определяют условия Google для Gemini API, а не настоящая Политика, — и поэтому вопрос в поддержку остаётся единственным написанным вами в oChat, чья судьба отчасти в чужих руках. Ради этого здесь и стоит отдельный раздел, и поэтому абзац ниже советует писать соответственно.

Человек берёт разговор на себя, когда у помощника нет надёжного ответа, когда вы сообщаете о поломке или как только вы просите специалиста, — и оператор видит переписку целиком, вместе с репликами помощника. Помощника мы можем и выключить совсем: тогда поддержка — люди с первого сообщения. Практическое следствие для вас — то, что сказано в Разделе 5.7: вопрос в поддержку стоит писать, исходя из того, что его прочтёт модель стороннего поставщика, потому что она его прочтёт.

3.8 Служебные оповещения в Telegram

Telegram — наши серверы отправляют служебные оповещения в закрытый чат Telegram, который читает наша команда: аккаунт попросил об удалении, аккаунт закрыт автоматически, платёж не прошёл, фоновая задача упала. Уходят они через Bot API Telegram, а Telegram в Европейском союзе не учреждён (Раздел 8).

Эти оповещения не обезличены, и мы лучше скажем об этом прямо, чем оставим впечатление, будто они обезличены. В шапке оповещения стоит идентификатор учётной записи — внутренний UUID — того человека, о котором событие, а в теле короткое описание самого события: для удаления или блокировки — что произошло и когда наступает срок зачистки. Чего в них нет — содержимого сообщений, контактов и вложений, а идентификатор в них внутренний, это не ваш номер телефона. Раздел 9 к ним не относится. Сроки хранения там описывают наши собственные базы и журналы, а оповещение — это сообщение в чате: оно лежит в этом чате до тех пор, пока его оттуда не удалят. Мы говорим это потому, что честный раздел о сроках не может обещать тридцати дней для копии, лежащей там, где мы не убираем.

4. Ваша адресная книга

Ваши контакты к нам не попадают ни в каком виде — ни исходными номерами, ни хешами, ни хешами с солью. Поиска по контактам нет: подсказать, кто из ваших знакомых уже пользуется oChat, мы не можем, потому что не знаем, кто они. Если Приложение когда-нибудь предложит позвать кого-то, оно сделает это системным экраном обмена или выбора контакта — тем, который не передаёт нам ничего: человека выбираете вы, ваша операционная система открывает ваш мессенджер, и приглашение уходит от вас, а не от нас.

Людей находят по юзернейму: вы набираете тот, который вам дали, или открываете присланную ссылку. Это весь механизм. Он менее удобен, чем сверка адресной книги, и это осознанный размен: адресная книга — это карта всех, кого вы знаете, включая тех, кто ничего нашего не устанавливал и ни на что не соглашался.

5. Хранение данных и безопасность

5.1 При передаче

Весь трафик между Приложением и нашими серверами, а также между нашими серверами и поставщиками, шифруется по TLS.

5.2 Каждая беседа — приватная

Это самое важное в настоящей Политике, поэтому сказано прежде всего остального:

• Каждая беседа в oChat зашифрована сквозным шифрованием всегда. Беседа — это либо диалог двух людей, либо группа, и обе приватны: переключателя, который выключил бы шифрование, не существует, и сделать беседу публичной нельзя. Это утверждение о пути сообщения и о наших серверах; что хранит ваше собственное устройство — в Разделе 5.10.
• Каналов и публичных групп больше нет. Создать канал больше нельзя, а существующие каналы закрываются и удаляются вместе с содержимым. Группы, которые были публичными, переводятся в приватные: участники остаются, публичный адрес освобождается, и после этого войти в группу можно только если вас добавил участник или по ссылке-приглашению, и написанное в ней шифруется так же, как в любой другой группе. То, что было написано в такой группе, пока она была публичной, зашифровано не было и задним числом зашифрованным не становится: пока его не удалят с наших серверов в тот срок, который Раздел 5.3 называет для всех прежних сообщений, оно лежит там в читаемом виде.

Единственная незашифрованная беседа — ваша переписка с нашей поддержкой, и приложение говорит об этом в ней самой: Раздел 5.7.

5.3 Ключи — и сколько сообщение остаётся у нас

Ключи создаются на вашем устройстве и уникальны для вас. Открытый ключ к нам попадает — иначе вам никто не сможет ничего зашифровать. Закрытый попадает в одном-единственном виде: завёрнутым в ключ, выведенный из вашего кода восстановления, — чтобы ваше новое устройство могло вернуть ключ по этому коду. Сам код восстановления к нам не попадает никогда, показывается вам один раз и не выводится ни из чего, что у нас есть; без него завёрнутый блоб для нас просто набор байтов.

Из этого следует главное: расшифровать вашу приватную переписку мы не можем ни по запросу, ни по решению суда, ни по собственному решению — не потому, что обещаем не делать этого, а потому, что единственное, чем это можно было бы сделать, — единственное, чего у нас нет. Прочитать чужую приватную переписку невозможно по той же причине: она зашифрована только для устройств её участников.

Мы формулируем это так подробно вместо короткого «ключи к нам не попадают» — короткая фраза была бы неправдой.

Наши серверы передают сообщения, а не хранят вашу историю. Сообщение и вложения приходят к нам зашифрованными, и держим мы их только до тех пор, пока каждое устройство, которое должно их получить, не подтвердит, что сохранило их: каждое устройство, на котором выполнен вход, у каждого получателя — и другие ваши устройства тоже. Фотографии, файлы и голосовые сообщения приложение скачивает сразу, как только приходит сообщение, так что подтверждение относится и к ним. После этого мы удаляем содержимое — зашифрованный текст, его ключи и файлы вложений. Устройство, которое за сообщением не приходит, бесконечно не ждут: через тридцать (30) дней после отправки содержимое сообщения удаляется, получили его все устройства или нет, и устройство, вернувшееся позже, его уже не получит. Тридцать дней — это потолок: срок дольше наши серверы не принимают, только короче.

Кое-что заставляет сообщение ждать дольше, чем занимает доставка, — в пределах этого потолка, — и это стоит знать: получатель, у которого устройство выключено или не в сети; устройство с версией приложения, выпущенной до этой модели, — оно никогда не подтверждает, что сохранило; и получатель, который в последние тридцать дней вышел из учётной записи на всех устройствах, — для него сообщение ждёт так же, как ждало бы выключенный телефон, чтобы оказаться на месте, когда он войдёт снова. Устройство, которое тридцать дней никто не открывал, ждать перестают.

Дольше содержимого живёт запись без него: кто отправил сообщение, в какую беседу, когда, какого оно вида, на какое сообщение отвечает или из какой беседы переслано, было ли оно изменено или удалено и какие на нём реакции. Эта запись нужна, чтобы устройство, побывавшее офлайн, догнало переписку в правильном порядке, и она тоже удаляется, когда сообщению исполняется тридцать дней. То немногое, что остаётся дольше, перечислено в Разделе 5.5.

Сообщения, отправленные до того, как эта модель вступила в силу (6 октября 2026 года), остаются на наших серверах в том виде, в каком хранились, — шифротекстом либо в читаемом виде для групп, которые были публичными (Раздел 5.2), — чтобы текущие версии приложения могли скачать их на ваши устройства. Через тридцать (30) дней после вступления модели в силу — 5 ноября 2026 года — они удаляются с наших серверов — и содержимое, и запись, в том числе «Избранное», которое прежние версии приложения хранили там.

Удаление сообщения — это «удалить у всех», и другого вида удаления текущее приложение не предлагает. Текст удалённого сообщения уходит с наших серверов сразу, файлы — в течение тридцати (30) дней, а само удаление доходит до каждого устройства каждого участника, которое ещё получает эту беседу. Когда записи о сообщении больше нет, наши серверы уже не знают, кто его написал, и удалить его у всех можно только там, где этого не нужно доказывать: владелец или администратор группы удалить его ещё может, а больше никто, включая автора. Выход из группы и уход чата в архив удалением не являются и не стирают ничего.

5.4 Чем вы за это платите — прямо

Раз мы не можем прочитать ваши сообщения и не храним их, мы не можем их и восстановить:

• история вашей переписки живёт только на ваших устройствах. Резервной копии мы не делаем — ни в своём хранилище, ни в чужом, а приложение помечает свою историю и свои медиа как исключённые из системных резервных копий — и на платформах Apple, и на Android;
• на новое устройство история попадает только с другого вашего устройства, где она есть, переносом, который вы подтверждаете на обоих (Раздел 5.12). Код восстановления возвращает ваш ключ — то есть новое устройство сможет читать сообщения, которые придут после этого, — но историю он не возвращает. Потеряли все устройства, на которых была история, — история потеряна, с кодом или без, в том числе для нас;
• уведомление сообщает, что пришло сообщение, и больше ничего: текста в нём нет, и мы его не присылаем;
• поиск работает на вашем устройстве и по тому, что на нём есть.

5.5 Что мы видим

Шифрование защищает содержимое, но не сам факт переписки. Чтобы доставлять сообщения, мы обрабатываем метаданные: идентификатор вашей учётной записи, идентификаторы чатов, в которых вы состоите, время отправки сообщения и его размер, а также запись о каждом сообщении без содержимого, описанную в Разделе 5.3, — тридцать дней. Два следа беседы остаются, пока существует сама беседа: докуда дочитал каждый участник и какие номера сообщений в ней закреплены — номер, а не сообщение.

Звонки добавляют к этому второй вид метаданных, и его стоит назвать отдельно, потому что он не проходит мимо, а записывается: это запись о звонке из Раздела 1 — оба участника, отметки времени, длительность, голос или видео, чем кончился, регион звонившего, напрямую или через ретранслятор. Удалённое сообщение уходит; строка о звонке, который вы сделали, остаётся — она в той же мере журнал вашего собеседника. Шифрование для неё не делает ничего, и ничто в этой Политике не утверждает обратного.

Доступ к продакшн-системам имеют только те, кому он нужен для работы Сервисов. В беседах этот доступ распространяется на перечисленные метаданные и ни на что больше: пути к содержимому не существует ни у кого, включая нас. Исключение одно — то, что названо в Разделе 5.2: написанное в группе, пока она была публичной, — до той даты, когда удаляются все прежние сообщения.

5.6 Жалобы и модерация

Пожаловаться можно было только на публичное сообщение, группу или канал, а ничего публичного больше нет. На приватную беседу пожаловаться нельзя, и причина не в правилах, а в арифметике: она зашифрована, прочитать её мы не можем, а жалоба, по которой заведомо ничего нельзя сделать, была бы обещанием разбора, которого не будет. Что можно сделать всегда — выйти из группы и заблокировать человека.

Жалоба, поданная, пока публичные беседы существовали, приходила к нам с адресом чата, номером сообщения, выбранной причиной и необязательным уточнением. Мы храним её до разбора и некоторое время после, чтобы повторные жалобы на один и тот же объект были видны как закономерность.

Наши сотрудники могут повесить на группу видимое предупреждение (например, «скам»), закрыть группу или заблокировать учётную запись — по тому, что можно установить без содержимого: по тому, что человек сам решит показать нам, когда пишет, или по автоматическим ограничениям из Раздела 6 Условий. Открыть беседу и посмотреть они не могут, и никакое количество жалоб такой возможности не открывает.

Синяя галочка у аккаунта или группы означает, что мы проверили: это тот, за кого он себя выдаёт. Её ставит человек и только руками — автоматически она не выдаётся никогда.

5.7 Переписка с поддержкой

Ваша переписка с нашей поддержкой не защищена сквозным шифрованием, и мы говорим об этом прямо в самой переписке. Чтобы ответить на вопрос, поддержка обязана его прочитать. Эти диалоги, включая реплики и оставленную вами оценку, доступны оператору, который их ведёт, и владельцу Компании, и хранятся, чтобы следующий вопрос можно было понять в контексте.

И первым ваш вопрос читает вообще не человек. Пока помощник не выключен нами, написанный вами текст уходит в Gemini компании Google, и первый ответ приходит оттуда, — что именно уходит, что остаётся и на какой срок, разобрано в Разделе 3.7. То есть список читающих не закрывается оператором и владельцем: в нём есть модель стороннего поставщика, и сам вопрос ради этого покидает нашу инфраструктуру. Больше ничто из написанного вами в Приложении так не делает: сообщения людям уходят их получателям и никому другому, шифротекстом, который мы открыть не можем.

Не отправляйте в поддержку пароли, коды восстановления и данные платёжных карт. Мы никогда их не спрашиваем, и ни одна задача поддержки их не требует.

5.8 Запросы государственных органов

Мы отвечаем только на запросы, юридически действительные и надлежащим образом вручённые. Выдать мы можем то, что у нас есть: юзернейм и отображаемое имя учётной записи, идентификатор, выданный провайдером входа, дату её создания, время последнего подключения, её устройства, идентификаторы бесед, в которых она участвует, записи без содержимого о сообщениях, которые она отправила за последние тридцать дней (Раздел 5.3), и записи о звонках из Раздела 1 — кто кому звонил, когда, сколько длился разговор и чем кончился. Номера телефона среди этого нет — мы его не собираем. Содержимое сообщений, их вложения и ключи выдать тоже не можем: то, что у нас от них есть, — шифротекст, и только в сроки из Раздела 5.3, и на такой запрос мы не в состоянии ответить ничем читаемым. Исключение одно, до даты из Раздела 5.3, — написанное в группе, пока она была публичной: оно не зашифровано.

Мы не будем строить обход собственного шифрования ни по чьей просьбе — ни коммерческой, ни государственной. Нет ни копии вашего ключа, которую могли бы открыть мы, — та, что у нас есть, заперта вашим кодом восстановления (Раздел 5.3), — ни мастер-ключа, ни скрытого дополнительного получателя, ни механизма, которым такой можно было бы добавить к уже отправленным сообщениям. Если какая-либо юрисдикция потребует ослабить эту архитектуру как условие работы в ней, мы прекратим оказание Сервисов в этой юрисдикции, а не выполним требование, и скажем об этом здесь и в Приложении до того, как решение вступит в силу: изменение такого рода меняет то, чем является oChat, и вносить его молча мы права за собой не оставляем.

Мы уведомляем пользователя, чьи данные запрошены, до того как что-либо раскроем, — кроме случаев, когда это запрещено законом или когда есть непосредственная угроза жизни. Когда запрет перестаёт действовать, мы уведомляем.

5.9 Утечки

Если нарушение безопасности персональных данных с высокой вероятностью повлечёт риск для ваших прав, мы уведомляем компетентный надзорный орган без неоправданной задержки и, когда это выполнимо, в течение 72 часов — как требуют ст. 33 GDPR и сербский LPDP. Если риск для вас высокий, уведомляем и вас напрямую.

Утечка с наших серверов раскрывает шифротекст, а не содержимое ваших сообщений, — а когда прежние сообщения будут удалены (Раздел 5.3), только шифротекст сообщений младше тридцати дней, — тот самый случай из ст. 34(3)(a) GDPR, и главная причина, ради которой эта архитектура стоит своей цены. Это не обещание, что ничего не может пойти не так: метаданные из Раздела 5.5 — настоящие данные, и их утечка была бы настоящей. Написанное в группе, пока она была публичной, шифротекстом не является, и до даты из Раздела 5.3 утечка раскрыла бы именно его.

5.10 На вашем собственном устройстве

Копия вашей переписки, которая лежит на вашем устройстве, хранится расшифрованной. Сквозное шифрование закрывает путь сообщения и наши серверы: у нас лежит шифротекст, и почему мы не можем его открыть, сказано в Разделе 5.3. Местная база, из которой приложение рисует ваш список чатов, — другое дело: в ней сообщения лежат открытым текстом — и на Android, и на iOS с macOS. Мы пишем это здесь, чтобы «зашифрованы всегда» не читалось как утверждение про ваш телефон: им оно не является.

Это осознанный размен, а не недосмотр. Ключу пришлось бы лежать на том же устройстве, что и база, — шифротекст защищал бы почти ни от чего, зато заставлял бы приложение разворачивать каждое сообщение на каждую прокрутку списка. Защищает эту базу то, где она лежит: собственный каталог приложения, который другие приложения на устройстве прочитать не могут.

Следствие из этого практическое. Тот, кто держит в руках ваше разблокированное устройство, прочтёт вашу переписку в приложении — как и тот, кто умеет достать с устройства каталог приложения.

Теперь эта база — единственное место, где существует ваша история, и приложение, начиная с версий, выпущенных после 7 октября 2026 года, обращается с ней соответственно. Выход из учётной записи — намеренный или потому, что закончилась сессия, — её не стирает: история остаётся на устройстве, закреплённая за этой учётной записью, и снова на месте, когда вы входите той же учётной записью. Другая учётная запись на том же устройстве видит только свою историю и не может ни прочитать, ни выгрузить вашу. Удаление учётной записи стирает её историю на том устройстве, с которого вы её удаляете, а удаление приложения стирает всё, что оно хранило. Прежние версии приложения при выходе стирают историю на устройстве. Поэтому устройство, которое вы кому-то передаёте, должно быть без приложения, а не просто с выполненным выходом. «Избранное» живёт здесь и только здесь: версии приложения, выпущенные после 7 октября 2026 года, не отправляют на наши серверы ни его текст, ни его файлы.

5.11 Кому видно, кто состоит в беседе

В группе список участников открыт каждому участнику: отображаемые имена, юзернеймы, аватары и строка «в сети» или «был в сети» — там, где это разрешает настройка приватности самого человека. Группа этим и является, а вход в неё — согласие с этим.

Этот список есть и на наших серверах — с ролью каждого участника и с тем, кто кого добавил: без него нельзя понять, куда доставлять сообщение, — а вместе с ним название группы, её аватар, её настройки и ссылки-приглашения. Ничто из этого не зашифровано, и хранится оно, пока существует группа.

5.12 Перенос истории на новое устройство

Раз история живёт на ваших устройствах, на новое она попадает только с другого вашего устройства, где она есть, — iPhone, Mac или телефона на Android, на котором выполнен вход в ту же учётную запись. Новое устройство просит; старое показывает запрос вместе с платформой нового устройства, его названием, страной и датой, когда на нём впервые выполнили вход, — и перенос начинается, только когда вы введёте на старом устройстве шестизначный код, который показывает новое. Этот код к нам не уходит, и он устроен так, что подменённый ключ изменил бы его: так два устройства убеждаются, что говорят друг с другом, а не с кем-то посередине, включая нас.

Затем старое устройство собирает вашу историю — беседы, в том числе «Избранное» и беседы, из которых вы вышли, с их фотографиями, файлами и голосовыми сообщениями — в архив, зашифрованный ключом, созданным для этого одного переноса, и передаёт этот ключ вместе с ключом вашей учётной записи новому устройству в таком виде, который может открыть только оно. Архив идёт через наше хранилище зашифрованными частями, которые мы прочитать не можем. Он удаляется, когда новое устройство подтверждает импорт, когда любое из устройств отменяет перенос или когда перенос истекает: через двадцать четыре (24) часа без активности и в любом случае через семь (7) дней после запроса. То, что мы храним о завершённом переносе, — его состояние, размер, названия, платформы и страны обоих устройств — удаляется сутки спустя.

Перенос передаёт всю вашу историю и ваш ключ, поэтому подтверждайте его, только если новое устройство у вас в руках. Тот, кто завладел вашей учётной записью Apple или Google либо вашими адресом почты и паролем, может запросить перенос, но не может довести его до конца, пока код с его устройства не введут на вашем.

5.13 История для того, кого вы добавили в группу

Если настройки группы разрешают новым участникам видеть прежние сообщения, то, когда вы добавляете в неё человека, ваше устройство отправляет ему недавнюю историю: последние сто (100) сообщений за последние четырнадцать (14) дней из тех, что есть на вашем устройстве, с миниатюрами и с файлами не больше шестнадцати (16) МиБ каждый, всего не больше двухсот пятидесяти шести (256) МиБ, — зашифрованную для ключей добавленных вами людей и ни для кого больше. Она проходит через наше хранилище и удаляется, когда её скачают все устройства нового участника, или через семь (7) дней после отправки — что наступит раньше. Отправить историю участнику может только тот, кто его добавил; вошедший по ссылке-приглашению её не получает.

Приложение нового участника проверяет, что каждое сообщение этой истории совпадает с записью, которая ещё есть на наших серверах, — отправитель и время, — и показывает, что историю прислал добавивший его участник. Там, где сравнивать уже не с чем, потому что содержимого на сервере нет, текст и файлы — на совести этого участника.

5.14 Что наши серверы хранят в любом случае

«Мы не храним ваши сообщения» — правда; «мы не храним ничего» было бы неправдой. Среди того, что остаётся на наших серверах независимо от правила тридцати дней, — следующее:

• ваша учётная запись и профиль — идентификатор входа, отображаемое имя, юзернейм, описание, аватар, эмодзи-статус и настройки приватности — и ваши решения о том, кто может вам писать;
• ваш открытый ключ и копия закрытого ключа, запертая вашим кодом восстановления (Раздел 5.3);
• ваши устройства и сеансы и их push-токены (Раздел 1);
• список ваших бесед с тем, что вы для каждой задали, — без звука, закреплена, в архиве, — докуда вы дочитали и время последнего сообщения, а также ваши папки чатов — с названиями и беседами в них;
• группы — как описано в Разделе 5.11 — и номера закреплённых сообщений;
• записи о звонках (Раздел 1);
• ваша переписка с поддержкой — в читаемом виде (Раздел 5.7) — и уже поданные жалобы (Раздел 5.6);
• подписки, покупки, ваш баланс звёзд и операции с ним; если вы ими пользуетесь — ваш профиль, комнаты и очки в игре в рисование, а также подписка «Защита» с зарегистрированными в ней устройствами и их счётчиками трафика;
• технические журналы и резервные копии баз — в сроки из Раздела 9.

6. Ваши права

В зависимости от вашего местонахождения применимое законодательство о защите данных (такое как GDPR ЕС или сербский Закон о защите персональных данных) может предоставлять вам следующие права в отношении ваших персональных данных:

• право на доступ — получить подтверждение того, обрабатываем ли мы ваши персональные данные, и копию этих данных;
• право на исправление — потребовать исправления неточных или неполных данных;
• право на удаление данных («право быть забытым»);
• право на ограничение обработки;
• право на переносимость данных — получить данные вашей учётной записи в структурированном, машиночитаемом формате. Содержимое ваших сообщений в него не входит и войти не может: историю мы не храним, а то, что проходит через нас, — шифротекст, который мы не в состоянии открыть. История вашей переписки — на ваших устройствах, там, где ключи;
• право на возражение против обработки;
• право отозвать согласие в любое время, если обработка основана на согласии;
• право подать жалобу в надзорный орган. В Сербии надзорным органом является Уполномоченный по информации общественного значения и защите персональных данных (poverenik.rs). Резиденты ЕС могут обратиться в орган по защите данных в своей стране проживания.

Чтобы воспользоваться любым из этих прав, свяжитесь с нами по адресу электронной почты из Раздела 11. Мы отвечаем в течение тридцати (30) дней.

Как мы проверяем, что это вы. Мы просим отправить запрос из самой учётной записи, через раздел поддержки в Приложении: вход в учётную запись и есть подтверждение. Если войти уже нельзя — напишите нам с той учётной записи Apple или Google либо с того адреса почты, с которыми вы входите в oChat, и мы сверим соответствие. Копию документа, удостоверяющего личность, мы не запрашиваем и по запросу, который не удаётся связать с учётной записью, не действуем — иначе это была бы процедура, по которой посторонний человек получает или стирает ваши данные убедительным письмом.

Чего удаление достигает, а чего нет. Удаление учётной записи опустошает ваш профиль и убирает записи, принадлежащие только вам. Отправленные вами сообщения оно не убирает: они остаются в чатах тех, кому вы их отправили, — на их устройствах, потому что отправленное вами — половина чужой переписки, и вынуть его значило бы переписать чужую историю за человека; на наших серверах — лишь столько, сколько любое сообщение (Раздел 5.3). Что именно удаляется, что опустошается и что остаётся — в Разделе 9. Да и решись мы иначе, копии на их устройствах расшифровываются только их ключами и мы бы до них не дотянулись: это то же самое свойство, которое не пускает нас в вашу переписку, только с другой стороны. Если нужно, чтобы сообщение исчезло из чужого чата, удалите само сообщение до того, как удалите учётную запись, — или попросите собеседника.

Удалить учётную запись можно в любой момент прямо из Приложения; что именно и когда удаляется — см. Раздел 9.

7. Конфиденциальность данных детей

Для использования oChat вам должно быть не менее 16 лет. Приложение не предназначено для тех, кто младше, и мы сознательно не собираем персональную информацию у детей. Если нам станет известно, что учётная запись принадлежит человеку младше 16, мы удалим её вместе со связанными данными.

Шестнадцать, а не тринадцать — выбор осознанный. Статья 8 GDPR позволяет каждой стране ЕС устанавливать возраст цифрового согласия в диапазоне от 13 до 16, и более низкая планка обязала бы нас получать и проверять родительское согласие в тех странах, где планка выше. Механизма для этого у нас нет, а правило, которое мы не в состоянии исполнить, хуже более строгого, которое исполнить можем.

8. Международная передача данных

Ваши данные могут передаваться и обрабатываться в странах, отличных от страны вашего проживания. Там, где передачу организуем мы, она опирается на следующее:

• Наши серверы и базы данных работают в Европейском союзе (Амстердам, Нидерланды), там же находится объектное хранилище, через которое проходят зашифрованные вложения и переносы истории (Западная Европа). Для резидентов ЕС это вообще не трансграничная передача.
• Поставщики, зарегистрированные в США — Cloudflare, Railway, Google (Firebase Authentication, Cloud Messaging, Analytics, Crashlytics, Google Play и Gemini API), Apple, Amplitude, Sentry и Polar — обрабатывают данные по нашему поручению на основании Стандартных договорных условий Европейской комиссии вместе с дополнительными мерами, которые каждый из них публикует.
• Текст вопроса в поддержку покидает нашу инфраструктуру и уходит в Gemini API компании Google, чтобы на него ответили (Раздел 3.7), — на тех же Стандартных договорных условиях, что и у поставщиков выше. Мы отводим ему отдельную строку, а не вписываем в предыдущую, потому что он другого рода: те получают идентификаторы, метаданные и диагностику, а этот — то, что вы написали своими словами.
• Служебные оповещения уходят в Telegram (Раздел 3.8). Эту передачу совершаем мы сами, и уходит она в мессенджер, а не обработчику, которого мы для этого наняли: Telegram в Европейском союзе не учреждён, и решением об адекватности это плечо не покрыто. Едет туда идентификатор учётной записи и описание события — содержимого сообщений не едет никогда, — и лежит оно в этом чате, пока мы его оттуда не удалим.
• Обратный прокси для пользователей из Российской Федерации (Раздел 3.3) решением об адекватности тоже не покрыт. Через него идёт зашифрованный трафик, TLS терминируется в России. Проходит там содержимое бесед — шифротекстом, который мы и сами прочитать не можем, кроме написанного в группах, пока они были публичными, — до даты из Раздела 5.3; ваша переписка с поддержкой, которая сквозным шифрованием не защищена (Раздел 5.7); и метаданные соединения, видимые любому прокси: адрес источника, хост назначения, время и объём.

9. Сроки хранения

• Сообщения и вложения хранятся в виде шифротекста только до тех пор, пока их не сохранят все устройства, которым они адресованы, и не дольше тридцати (30) дней; запись о сообщении без содержимого удаляется, когда сообщению исполняется тридцать дней (Раздел 5.3). Удалённое вами сообщение сразу исчезает из Приложения, его текст сразу уходит с наших серверов, а файлы — в течение тридцати (30) дней.
• Сообщения, отправленные до вступления этой модели в силу, — в том числе написанное в группах, пока они были публичными, и «Избранное», которое хранили прежние версии приложения, — удаляются с наших серверов через тридцать (30) дней после её вступления в силу — 5 ноября 2026 года, — и содержимое, и запись (Раздел 5.3).
• Переносы истории между вашими устройствами удаляются из нашего хранилища, когда новое устройство подтверждает импорт, когда перенос отменён или когда он истёк — через двадцать четыре (24) часа без активности и не позже чем через семь (7) дней после запроса; запись о завершённом переносе — через сутки после завершения (Раздел 5.12). История, отправленная участнику, которого вы добавили в группу, удаляется, когда её скачают все его устройства, или через семь (7) дней после отправки (Раздел 5.13).
• Резервные копии считаются в копиях, а не в днях: мы храним три последние удачные суточные копии каждой базы, остальные удаляем. Из этого следуют две вещи, и ни одна из них не то, что обещали бы «три дня». Отсчёт начинается только тогда, когда данные действительно ушли из базы: содержимое сообщения уходит из неё после доставки и самое позднее в сроки из Раздела 5.3, и свободны от него лишь те копии, что сняты после этого. А если ночная задача упала, копии, которые она должна была заменить, остаются: копии старше тридцати (30) дней удаляются, но самая свежая копия базы — никогда, так что задача, вставшая на больший срок, оставляет одну устаревшую копию, а не ни одной, пока её не заменит новая. В обычном случае содержимое перестаёт встречаться в копиях примерно через три дня после того, как ушло из базы. Это то, как обычно выходит, а не обещание, которое мы вправе дать.
• Вложения, загруженные, но так и не отправленные, удаляются через двадцать четыре (24) часа.
• Устройства, переставшие выходить на связь, сохраняют свою запись до тех пор, пока вы не отзовёте сеанс или не удалите учётную запись. Refresh-токен истекает сам через девяносто (90) дней и после этого не работает.
• Удаление учётной записи. Когда вы просите удалить учётную запись, зачистка происходит через тридцать (30) дней. Отсрочка сделана намеренно: удаление необратимо, ошибочное нажатие случается часто, а тот, кто угнал учётную запись, удаляет её первым делом, чтобы замести следы. Удаляются начисто записи, принадлежащие только вам: ваши устройства и сеансы, push-токены, список бесед и папки, по которым вы их разложили, хранящиеся у нас ваши контакты, ваша строка в справочнике юзернеймов, реакции и отметки о прочтении, список скрытых вами сообщений, а также записи о подписке, покупках и правах на платный доступ. Вместе с ними удаляются ваши копии ключей содержимого — именно поэтому после зачистки вашу сторону переписки не расшифровать никому, включая нас. На том устройстве, с которого вы удаляете учётную запись, приложение стирает и её историю (Раздел 5.10). Строка профиля не удаляется, а опустошается: снимаются отображаемое имя, юзернейм, описание, аватар, время последнего визита и ключевой материал, который разворачивается вашим кодом восстановления. Сама строка остаться обязана: на неё ссылаются сообщения в чужих беседах, и её удаление превратило бы отправителя в идентификатор, за которым ничего нет. Запись о входе в Firebase Authentication зачистка тоже удаляет: сначала она снимает связь этой записи с вашей учётной записью oChat, а затем удаляет из списка пользователей нашего проекта Firebase и саму запись — с вашим адресом почты и, если вы входили по почте, паролем. Если Firebase в этот момент недоступен, зачистка от удаления не отказывается и повторяет попытку, пока оно не пройдёт. Единственное исключение: если до зачистки вы снова вошли через тот же Apple ID, аккаунт Google или адрес почты и при этом появилась новая учётная запись oChat, запись о входе теперь принадлежит этой новой учётной записи и сохраняется.Удаление учётной записи не отменяет подписку. Подписка оформлена на ту учётную запись магазина, которая её купила; мы удаляем только свою запись о ней, а списания продолжаются, пока вы не отмените её в этом магазине; где именно — в Разделе 13 Условий.
• Удаление учётной записи: что остаётся и почему. Отправленные вами сообщения и вложения не удаляются с устройств тех, кому вы их отправили; на наших серверах они остаются лишь столько, сколько любое сообщение (Раздел 5.3). Отправленное вами лежит в чужом чате, и эта переписка в той же мере его, что и ваша; вынуть его значило бы забрать у человека половину его истории по вашему единоличному решению. По той же причине остаются записи о ваших звонках («пропущенный» на той стороне — его), закреплённые в группе сообщения, созданные вами группы — у них есть участники, и закрыть их значило бы удалить то, что принадлежит этим людям, — и ссылки-приглашения, которыми продолжают пользоваться другие: у них мы снимаем только названия, которые придумали вы. Ваше участие в беседах помечается как выход, а не стирается. Поданная вами жалоба на другого человека тоже остаётся: это запись о его поступке, а не о вашем. Остаётся и переписка с поддержкой — копия юзернейма в ней заменяется той же меткой. После зачистки всё это указывает на профиль, в котором ничего не осталось — ни имени, ни аватара, ни дороги обратно к вам, — но оно там остаётся, и решать вам стоит, зная это. Если нужно, чтобы что-то исчезло из всех копий, удалите само сообщение до удаления учётной записи: это другое действие, и оно до чужой стороны доходит — на условиях первого пункта этого раздела.
• Заблокированные учётные записи. Если учётная запись заблокирована по жалобе, мы храним запись о ней и саму жалобу сто восемьдесят (180) дней после блокировки — чтобы можно было рассмотреть обжалование и чтобы ту же учётную запись нельзя было просто создать заново. Если блокировка идёт по жалобе на приватную беседу, содержимого сообщений в этой записи нет — его у нас не существует. Если по жалобе на публичную группу или канал, поданной, пока они существовали, в ней хранится то сообщение, на которое пожаловались: жалоба, в которую нельзя посмотреть, — это жалоба, по которой нельзя ничего решить.
• Записи о звонках хранятся столько же, сколько существует беседа, которой принадлежат, и переживают удаление вашей учётной записи. Это сделано намеренно: строка — половина журнала звонков вашего собеседника, и стереть её значило бы вынуть «пропущенный звонок» из его истории по вашему решению. После зачистки ваша сторона этой записи указывает на учётную запись, в которой ничего не осталось.
• Собственный журнал помощника поддержки — вопросы и ответы (Раздел 3.7) — стирается через пятнадцать (15) дней. Сама переписка с поддержкой остаётся у нас на условиях, описанных выше.
• Технические журналы — время соединений, адреса, трассировки ошибок — хранятся тридцать (30) дней. Это не пожелание, а срок хранения у нашего хостинг-провайдера: через тридцать дней этих записей попросту не существует, и предъявить их невозможно.
• Служебные оповещения в Telegram (Раздел 3.8) — исключение из всего сказанного выше. Это сообщения в чате, а не строки в наших базах, и никакой срок их не гасит: они лежат там, пока их не удалят руками.
• Платёжные и бухгалтерские документы хранятся десять (10) лет, как того требует сербское законодательство о бухгалтерском учёте.

10. Изменения настоящей Политики конфиденциальности

Мы можем время от времени обновлять настоящую Политику. Новая версия вступает в силу с момента её публикации в Приложении или на нашем веб-сайте. Рекомендуем периодически просматривать Политику. Продолжение использования Приложения после публикации изменений означает ваше принятие обновлённой Политики. Если изменение существенно затрагивает обращение с содержимым сообщений, мы сообщим о нём в Приложении, а не только на этой странице.

11. Контактная информация

Если у вас есть вопросы о настоящей Политике конфиденциальности или вы хотите воспользоваться любым из прав, описанных в Разделе 6, пожалуйста, свяжитесь с нами:

Оператор персональных данных: Vitalii Sosin PR Beograd

Правовая форма: Индивидуальный предприниматель (preduzetnik)

Юридический адрес: Kneza Miloša 15, 11167 Beograd (Vračar), Republic of Serbia

Регистрационный номер (Matični broj): 68444683

Идентификационный номер налогоплательщика (PIB): 115539784

Email: [email protected]

Веб-сайт: ochat.club