Privacy Policy

Last updated April 19, 2026 · Effective April 7, 2026

At Umbrella X we take your privacy seriously and we keep this document short enough to read in one sitting. We do not show advertising. We do not sell your data. We do not share it with data brokers. We collect the minimum amount of information needed to run a working messenger, and the content of your messages is end-to-end encrypted so we cannot read it even if we are asked to. This policy explains exactly what we collect, why, how long we keep it, and the rights you have. If anything below is unclear, write to privacy@umbrellax.io and we will explain.

1. Introduction

This Privacy Policy describes how Umbrella X handles personal data when you use our messenger application on iOS, Android, or any future client (Web, Windows, macOS), and when you visit our website at umbrellax.io. It covers data processed when you register an account, send and receive messages, browse our website, contact support, or otherwise interact with the Service. It does not cover third-party services you may reach through links from inside our app or website; those have their own privacy policies and we encourage you to read them.

The data controller is UmbrellaX TOO, a limited liability partnership registered in the Republic of Kazakhstan under business identification number 260440006927, with its registered office at ul. Zheltoksan, d. 1/6, korpus 3, kv. 13, 090000 Uralsk, Kazakhstan. Throughout this document we refer to UmbrellaX TOO as "Umbrella X", "we", "us", and "our". We refer to the messenger and the website together as the "Service". We refer to you as "you" or "the user". For privacy matters contact privacy@umbrellax.io. Our Data Protection Officer is reachable at dpo@umbrellax.io.

This Privacy Policy forms part of our Terms of Service. Practical, day-to-day questions about how things work ("how do I delete my account?", "how do I report abuse?", "what does end-to-end encryption mean?") are answered plainly on the FAQ.

2. The data we collect

We collect the smallest amount of data we need to run a working messenger. The list below is exhaustive. If something is not on this list, we do not collect it. We do not require a phone number. We do not store your IP address. We do not ask for your email, your real name, your country, or your identity documents.

2.1 Account data

1. Public cryptographic key. An Ed25519 public key is generated on your device the first time you open the app. It is your only identifier in our system. We never see or store the matching private key, it stays on your device, protected by the operating system keystore (iOS Keychain, Android Keystore, WebAuthn/Passkey on the web) and your device biometric.
2. Username. A human-readable handle like @bright_falcon_42 is auto-generated so your contacts can find you by something easier than a 32-byte public key. You can change it at any time to whatever you want (4 – 32 characters, Latin letters, digits, underscore).
3. Region (cell ID). A single value from a short list of three: EU, UAE, or BVI. This tells our system which regional data centre your account lives in so your messages stay physically close to you for low latency. It is auto-assigned at sign-up based on the 2-letter country code our edge provider (Cloudflare) attaches to your request, we do not store the country code itself, only the resulting cell ID. You never have to pick anything. If you want to migrate your account to a different region (for example, from EU to BVI for maximum offshore protection), email privacy@umbrellax.io.
4. Registration date.

That is the complete list of what an account "is" to us. We do not know who you are. No phone number, no email, no name, no country string, no document.

2.2 Recovery material

When you register, the app shows you a 24-word recovery phrase (BIP-39 standard, the same approach used by cryptocurrency wallets). You save it somewhere safe. We do not see it, we do not store it, and we cannot recover it for you. If you lose both your device and the recovery phrase, the account is gone, there is no backup channel with a "reset password" button because there is no password for us to reset. This is the honest trade-off of a system that cannot read or impersonate its users: only you have the keys. On the web we additionally support WebAuthn/Passkey (FIDO2) tied to your device. As an option, the app can produce an encrypted cloud backup of your keys protected by a passphrase you choose (Argon2id + AES-256-GCM); we store the ciphertext but cannot decrypt it.

2.3 Envelope information

To deliver a message we need a small amount of envelope information, sender address, recipient address, time, size, and delivery status. The analogy is a postal envelope: the postman sees the addresses and the postmark, but the letter inside stays sealed. We see envelopes too, because we cannot route a message without knowing where it goes, but we do not see the message content, and we discard the envelope information as soon as the delivery is finished (typically minutes; see section 5). The message content itself is always encrypted on your device before it leaves: in Cloud-mode chats the per-conversation key is wrapped by five Sealed Servers under a 3-of-5 threshold (see section 8) and only unwrapped on authenticated user devices; in Secret-mode chats the key lives solely on participants' devices through MLS (Messaging Layer Security, IETF RFC 9420). In either case our servers handle ciphertext we cannot decrypt.

2.4 Device and technical data

1. Push notification token. Issued by Apple Push Notification Service (APNs) or Firebase Cloud Messaging (FCM). Used to deliver "you have a new message" alerts to your device.
2. App version and operating system. Used for compatibility and to prioritise security updates.
3. Device attestation ID. A short token issued by Apple App Attest, Google Play Integrity, or WebAuthn, which tells us "this really is a genuine iOS/Android/Web client, not a bot or an emulator". We use it for abuse prevention and rate-limiting, in place of the IP address most services rely on.

2.5 Optional add-ons you can attach yourself

1. Phone number (optional). If you want to be findable by friends through their address book, you can attach a phone number. We do not store the number or a hash of it. Instead, your device runs a cryptographic protocol (VOPRF) with our Sealed Servers: three of the five zones jointly apply a secret that none of them holds alone, your device unblinds the result, and we end up storing a derived one-way cryptographic fingerprint of the number, a short unique string that is stable for your number but from which the number cannot be recovered, mathematically, by anyone, by us, by a court, by the Sealed Servers themselves. This is not encryption (there is no key that could decrypt it); it is a one-way function. The Sealed Servers only perform this operation for requests carrying a valid Apple App Attest, Google Play Integrity, or WebAuthn proof from your device; a plain request from us ("is +7 777 123 45 67 a user?") gets rejected because we cannot produce that proof. A court order asking whether a specific phone number belongs to an account is something we physically cannot answer without the user's own device. See ADR-22 in our technical docs. You can remove your number at any time; the fingerprint is deleted and can never be regenerated without your device.
2. Display name, profile picture, bio / status text (optional). These live in an end-to-end encrypted profile blob stored on our server as ciphertext, indexed by your public key. The encryption key is generated on your device, restored by the same 24-word recovery phrase, and never leaves your keystore. When you add a contact (mutually), your device wraps a copy of the profile key for their public key and sends it through a sealed channel (Cloud-mode chats) or inside an MLS welcome message (Secret-mode chats); only authenticated contact devices can decrypt. We store only ciphertext. A court order on a specific public key will receive: username, registration date, region, and the encrypted blob, which is meaningless without the key we do not have. Two visibility modes: "Contacts only" (default, sealed), or "Public profile" (opt-in, plaintext copy in a separate public directory, for bloggers, channels, or businesses who consciously want visibility; enabling it requires explicit confirmation with an on-screen warning). Channels and bots are always public. See ADR-21.

2.6 Things we explicitly do not collect

1. IP address. We do not store IP addresses. Our gateway receives your traffic stripped of IP attribution at the edge; our rate-limiter keys off the device attestation ID, not the IP. A court order asking for "the IP history of user X" is something we cannot answer, we do not have it.
2. Email. We never ask for one. Recovery is through your 24-word seed, not through "send a reset link to your inbox".
3. Country string. Only the cell ID (1 of 3 values) is stored. The country code that Cloudflare attaches to your request is used for cell assignment and then discarded.
4. Real name, ID documents, address, date of birth. Not requested. The account is anonymous.
5. Message content. End-to-end encrypted; we cannot read it.
6. Plaintext address book contents. Contact discovery, available from our first release, runs the VOPRF protocol described in section 2.5: your device transforms each phone number in your book through the Sealed Servers into a one-way cryptographic fingerprint, sends the batch of fingerprints to us, and we reply which ones correspond to registered accounts. We never see the numbers, never see salted hashes, never see anything reversible. The Sealed Servers refuse to perform this transformation without a valid device-authenticity proof from Apple or Google.
7. Precise GPS or location history.
8. Browsing history, websites visited, or anything outside the app.
9. Advertising identifiers (IDFA, GAID).
10. Biometric data. Biometric unlock of the device keystore happens on-device only; we never see the fingerprint or face.

3. Why we use each item of data

We use each piece of data for one or more of the purposes below. We do not reuse data for unrelated purposes.

1. Public key, to identify your account cryptographically. Every message you send is signed with the matching private key on your device, which proves it came from your account without revealing anything else about you.
2. Username, to let your friends find you by something easier than a 32-byte public key.
3. Cell ID, to route your account to the right regional data centre so your messages live close to you. Assigned once at sign-up; used forever after.
4. Display name, profile picture, bio, to show other users who they are talking to. You control all three; they are optional.
5. Phone number hash (only if you attach one), to let other users find you if they have your phone number saved in their contacts. Stored as a salted SHA-256 hash, not the raw number.
6. Envelope information, to route messages to the correct recipient and report delivery state back to the sender. Discarded as soon as the delivery is finished (typically minutes).
7. Push tokens, to wake your device when a new message arrives. The push payload contains no message content.
8. Device attestation ID, to prove to our rate-limiter that the request is coming from a genuine iOS/Android/Web client and not a bot farm. It replaces the IP-based rate-limiting most services use.
9. App version and operating system, to maintain compatibility and to identify which builds are vulnerable when we publish a security update.

We do not use your data for advertising and we do not sell your data to anyone, ever.

4. Legal basis for processing (EU/EEA users)

If you are in the European Union, the European Economic Area, or the United Kingdom, the General Data Protection Regulation (GDPR) requires us to identify a lawful basis for each kind of processing. Our bases are:

1. Performance of a contract (Art. 6(1)(b) GDPR), for everything required to operate the Service: registering your cryptographic key, routing messages, delivering push notifications, and processing the optional phone hash if you chose to attach one.
2. Legitimate interests (Art. 6(1)(f) GDPR), for fraud prevention, abuse detection, and the security of our platform. Our interest is keeping the Service safe; we have weighed it against your interests and we believe it does not override them.
3. Legal obligation (Art. 6(1)(c) GDPR), when we are required to retain or disclose data by a valid legal process in our jurisdiction.
4. Consent (Art. 6(1)(a) GDPR), for any optional features that go beyond the basic Service. We will ask you clearly and you can withdraw consent at any time.

5. How long we keep your data

We do not really keep it. Almost nothing about you survives on our servers beyond the few minutes needed to actually deliver a message. This is by far the most aggressive retention posture in the messaging industry, and it is intentional.

The technical concept here is what we call "envelope information", the addresses, time, size, and delivery status of a message. The analogy is an ordinary postal letter: the postman sees the envelope (sender address, recipient address, postmark, weight) but the letter inside stays sealed. We see envelopes too, because we cannot deliver a message without knowing who it goes to. But we get rid of the envelope as soon as the delivery is finished.

1. Account record (public key, username, region of storage, encrypted profile, one-way cryptographic fingerprint of your phone number if you attached one), kept for as long as your account exists. When you delete your account, everything about you is purged immediately, the record, every reference to you in any other user's envelope information, any ciphertext still in the delivery queue, your notification address, your device-authenticity proof, your zone share of the phone fingerprint. No tombstone, no recovery window. Your public key is cryptographically unique (Ed25519, 256 bits), there is no replay risk that requires us to remember "this key was once used". On confirmation, you are gone.
2. Cascade delete to your contacts. When you delete your account, our server sends every one of your contacts a service message asking their app to remove its local copy of your conversations. Their app executes this without asking, no "save a copy" dialog, no confirmation. Online contacts process it immediately; offline contacts process it the next time they open the app. What we cannot do: erase screenshots, forwarded messages, or backups stored on their device by Apple/Google, those are outside our control and we say so plainly.
3. Envelope information (sender address, recipient address, time, size, delivery status, the postal-envelope equivalent), kept only as long as it is operationally needed. In practice: from the moment you send, through delivery to the recipient, through the read receipt being delivered back to you, typically minutes. After that we delete it. There is no 30-day window, no 90-day window, no abuse-prevention store of who-talked-to-whom. None of it.
4. Encrypted message content in the delivery queue (waiting for an offline recipient), held at most 24 hours. After 24 hours the ciphertext is discarded and the sender gets a "delivery expired" notification.
5. IP addresses, we do not store them at all. Not for a week, not for an hour, not for a second. Our gateway does not log them; our rate-limiter does not use them. Cloudflare sees IPs briefly at the edge for attack filtering under their own policy; we do not have access to their logs. Section 6 covers processors.
6. Notification address (the token Apple or Google gives us so we can wake your device), kept until it expires or you uninstall the app. Removed immediately on account deletion.
7. Device-authenticity proof (the short signature from Apple App Attest, Google Play Integrity, or WebAuthn that proves your client is a genuine iPhone, Android, or Web device, not a script), rotated every 14 days; old entries overwritten.
8. Anti-spam counters live in server memory only, not in any database, not in any backup. They reset on server restart. A new account is hard-limited to 20 messages and 20 contact-additions per day; this limit relaxes as your account ages without complaints. This is the entire spam-prevention apparatus, there is no behavioural-profile store, no "history of activity" record.
9. Operational backups (system configuration, schemas, deployments, not user data), retained for up to 14 days for disaster recovery and then overwritten.
10. Legal hold data, only when a valid court order in our jurisdiction compels us to preserve specific data, and only for the duration required.

What this means for law-enforcement requests in practice. A subpoena for "envelope information about user X over the past month" finds nothing, we kept it for minutes. A subpoena for "any data about a user who deleted their account two days ago" finds nothing at all, we have no tombstone. A subpoena for "the IP history of user X" cannot be answered, we never stored IPs. A subpoena for "is this phone number a registered user" cannot be answered, we hold a one-way cryptographic fingerprint, not the number, and the Sealed Servers will not transform a number into a fingerprint without the user's own authenticated device.

The trade-off we accept. Abuse complaints work only on the spot, your client app attaches the offending message itself as evidence at the moment you tap "Report"; we do not keep an after-the-fact archive. If you missed the moment (the sender deleted, the account was wiped), the complaint cannot be reconstructed from our side. Customer support cannot help with "what happened to a message five minutes ago" because we have no data to look at. These are honest costs of a privacy-first design and we state them rather than hide them. See ADR-25 in our technical docs for the full reasoning.

6. How we share data

We do not sell your data. We do not share your data for advertising. The only times we share data are:

1. Infrastructure providers (processors) we use to run the Service:
   • Cloudflare (United States / global edge), DDoS protection and edge delivery. Cloudflare sees your IP at the edge under their own terms; the only data they pass on to us is a 2-letter country code (used once for cell assignment) and a request ID. They act as a data processor for traffic filtering purposes under their standard Data Processing Addendum.
   • Apple Push Notification Service (APNs), for iOS push notifications. We send APNs a device token and an encrypted notification payload; no message content in plaintext.
   • Firebase Cloud Messaging (FCM), for Android push notifications. Same pattern.
   • Hosting providers, Hetzner (Germany) for Cell EU, regional providers for Cell UAE and Cell BVI. Act as processors for raw storage and compute; they see only ciphertext and short-lived envelope information.
2. Law enforcement, when we receive a legally valid request from a Kazakhstan court or another competent authority recognised under Kazakhstan law. We disclose only the data we are required to disclose, never more, and we challenge requests that are overbroad or improper. We cannot disclose message content because we do not hold the decryption keys, in Cloud mode they are split across five sealed key servers under 3-of-5 threshold and released only to user devices; in Secret mode they live only on participants' devices. We cannot disclose IP history because we do not store it.
3. Verified victim-requested external reports (NCMEC / StopNCII / GIFCT / Polaris / case-by-case). See our Victim Support Portal for the verification procedure and the Warrant Canary for public counters. Never automatic; always at the explicit, verified request of the victim or their representative.
4. In a corporate transaction such as a merger or acquisition. The acquiring entity inherits the obligations of this Privacy Policy.

7. International transfers and data residency

UmbrellaX TOO is a company registered in the Republic of Kazakhstan, but the physical location of your data is one of three regional cells, auto-assigned at sign-up based on your access region:

• Cell EU (Hetzner, Germany), accounts from СНГ (Russia, Belarus, Ukraine, Kazakhstan, Uzbekistan, Kyrgyzstan, Tajikistan, Armenia, Georgia, Azerbaijan), Iran, Turkey, and the European Union. GDPR applies.
• Cell UAE (Dubai), accounts from the UAE, Saudi Arabia, Qatar, Bahrain, Kuwait, Oman, India, Pakistan.
• Cell BVI (British Virgin Islands, offshore), accounts from all other countries (Americas, Africa, Australia, China, Japan, South Korea, Singapore, and the rest of the world).

We intentionally do not store СНГ user data in Kazakhstan, even though our parent company is Kazakhstan-based. The separation (KZ legal entity + EU data residency) protects you if local law in any one jurisdiction shifts unexpectedly. Many privacy-focused services follow the same pattern.

Encryption keys for Cloud-mode chats are not stored in the same cells as your ciphertext. They live in a separate set of five sealed key servers placed in five different countries (Germany, Finland, Netherlands, UAE, and the British Virgin Islands), each holding one share of a split master key under a 3-of-5 threshold scheme. A single compromised cell or a single legal jurisdiction cannot recover keys; an attacker would need to compromise at least three sealed servers simultaneously in three different countries. Administrative access to these sealed servers was destroyed in a notarised one-time ceremony (the "master key destroyed and publicly verified" commitment), so no employee, founder, court order, or insider can retrieve the master key through normal channels, only user devices receive keys directly, after signing a request with their own cryptographic key. See the protocol whitepaper for the full description of this sealed-boxes architecture.

Push notifications are routed briefly through Apple (APNs, United States) and Google (FCM, United States); the payload we send them is an encrypted "wake-up" ping, never your message content. When we transfer personal data outside your country we rely on appropriate safeguards, including the Standard Contractual Clauses approved by the European Commission (for EU users) and equivalent mechanisms recognised by Kazakhstan law.

If you want your account migrated between cells (for example, to Cell BVI for maximum offshore protection), email privacy@umbrellax.io. Migration is free and preserves your history.

8. Security

We protect your data with the following measures:

1. Two encryption modes, one promise: we cannot read your messages in either.
   • Cloud mode (default for new chats): message content is encrypted with a per-conversation key that is wrapped by five geographically distributed sealed key servers under a 3-of-5 threshold scheme, as described in section 7. Our servers hold the ciphertext; the sealed key servers hold the split master key and will only release shares of it directly to your authenticated devices. Administrative access to the sealed servers was destroyed after initial setup, so we physically cannot unwrap the key ourselves or be compelled to. Cloud mode is what lets multi-device synchronisation, bots, large groups, and channels work without giving us the ability to read content.
   • Secret mode (opt-in, per chat): pure end-to-end encryption using MLS (Messaging Layer Security, IETF RFC 9420). Encryption keys live only on the devices of the participants; no server, including our sealed key servers, ever sees them. In exchange, Secret chats do not synchronise to new devices and support smaller group sizes (around one thousand participants, the practical MLS limit).
2. Post-quantum hybrid key exchange from day one. Every chat, Cloud or Secret, combines classical X25519 with the NIST-ratified post-quantum ML-KEM-768 (Kyber, FIPS 203, August 2024). If a future quantum computer breaks X25519, the post-quantum layer still protects you; if an unforeseen classical flaw is found in ML-KEM, X25519 protects you. The goal is that ciphertext captured today stays unreadable in thirty years.
3. All calls are end-to-end encrypted, and by default the other party's IP address is hidden. Voice and video calls use DTLS-SRTP with keys derived on the participating devices. Because establishing a direct peer-to-peer connection requires both sides to exchange IP addresses, we do not try direct connection by default, the default path is through our TURN relay, which forwards encrypted packets without seeing their content and without revealing either party's IP to the other. "Fast direct calls" can be enabled in Settings with an explicit warning about IP exposure. For journalists, activists, lawyers, and anyone requiring stronger isolation, an opt-in "Maximum call privacy" mode routes the call through two relays in different jurisdictions, neither relay alone knows the "A ↔ B" association. Group calls (3+ participants) go through a Selective Forwarding Unit (SFU) that architecturally hides each participant's IP from every other participant. See ADR-23.
4. End-to-end encrypted profile. Your display name, avatar, and bio are stored on our server as a sealed ciphertext keyed by a profile key that never leaves your device (see section 2.5). Only your mutually-added contacts can decrypt. A public profile option exists for users (bloggers, channels, businesses) who consciously want visibility.
5. Private contact discovery via one-way cryptographic fingerprints. If you attach a phone number, it is transformed by a 3-of-5 VOPRF protocol with our Sealed Servers into a one-way fingerprint from which the number cannot be recovered (see section 2.5). Without your authenticated device we cannot check whether a given phone number is ours, this is physically enforced, not a policy promise.
6. Transport encryption with TLS 1.3 between your device and our servers, with strong cipher suites and perfect forward secrecy.
7. Encryption at rest for the small amount of envelope information transiently stored, full-disk encryption on every server, and mutual TLS between services.
8. Master key destroyed and publicly verified. The sealed key servers publish AMD SEV-SNP attestation reports every 24 hours to an append-only transparency log, so anyone can verify that the running software is the one we published and that no administrative back door has been added.
9. Strict access controls: only a small number of engineers have production access, all access is logged and audited, and no engineer has any access to the sealed key servers after the initial ceremony.
10. Regular security review, an annual external audit (scope includes protocol implementation, ceremony procedures, and the transparency log), and a responsible disclosure programme. If you discover a vulnerability, please report it to security@umbrellax.io and we will respond promptly.

9. Your rights

Depending on where you live, you have some or all of the following rights over your personal data. We will honour all of these rights, regardless of jurisdiction, where it is technically possible to do so.

9.1 Rights under the GDPR (EU/EEA/UK)

1. Right of access. You can ask us what personal data we hold about you and receive a copy.
2. Right to rectification. If something we hold about you is wrong, you can correct it.
3. Right to erasure ("right to be forgotten"). You can ask us to delete your data, subject to legal retention requirements.
4. Right to restrict processing. You can ask us to limit how we use your data while a dispute is being resolved.
5. Right to data portability. You can request your data in a machine-readable format.
6. Right to object. You can object to processing based on legitimate interests.
7. Right to withdraw consent. Where we rely on consent, you can withdraw it at any time without affecting prior processing.
8. Right to lodge a complaint with a supervisory authority in your country of residence.

To exercise any of these rights, write to privacy@umbrellax.io. We respond within 30 days.

9.2 Rights under the CCPA / CPRA (California residents)

California residents have additional rights under the California Consumer Privacy Act:

1. Right to know what personal information we collect, use, disclose, and (if applicable) sell.
2. Right to delete personal information we have collected.
3. Right to correct inaccurate personal information.
4. Right to opt out of the sale or sharing of personal information. We do not sell or share your data, so this right has no practical effect for our users, but we are stating it explicitly so you know.
5. Right to limit the use of sensitive personal information.
6. Right to non-discrimination for exercising any of these rights.

To exercise these rights, write to privacy@umbrellax.io.

9.3 Rights under Kazakhstan law on Personal Data and Their Protection

Residents of the Republic of Kazakhstan have rights under Law No. 94-V of 21 May 2013 on Personal Data and Their Protection, including the right to access, correct, block, and destroy their personal data, and the right to revoke consent. To exercise these rights, write to privacy@umbrellax.io. The original Kazakhstan-language text of the Law prevails over any English translation we may provide.

10. Cookies and local storage

Our website at umbrellax.io uses a small set of strictly functional local storage values. They stay on your device and are not sent to us or to any third party. The mobile application does not use cookies at all.

The website values are:

1. theme remembers whether you last chose light or dark mode, so the site does not flash the wrong colour on reload. Set only when you click the sun/moon icon in the header.
2. lang remembers your language preference on the landing page, so the site comes up in the language you picked last time. Set only when you pick a language from the dropdown.
3. ux-read:<slug>:<YYYY-MM-DD> stores a same-day marker on article pages after a qualified read. It is not sent to us. It only stops the same browser from counting the same article repeatedly in one local day.

Blog pages also use an aggregate read counter. The browser sends an empty same-origin request only after the article has been visible for at least 30 seconds and the reader has reached at least 60 percent of the article body. The read-counter log stores only the event time and article slug for aggregation. It does not store IP address, user agent, referrer, query string, cookie, account ID, or any browser fingerprint.

We do not use Google Analytics, Plausible, Matomo, or any other analytics product. We do not use Facebook Pixel, TikTok Pixel, or any other advertising pixel. We do not use session replay or heatmap tools. We do not embed YouTube videos, Twitter timelines, Facebook buttons, Disqus comments, or any other third-party widget that sets cookies from a foreign domain. Our fonts are self-hosted. Because everything we store is strictly necessary to remember your own choices and avoid repeated read counts from the same browser, consent under the GDPR and the ePrivacy Directive is not required, and we do not show a cookie banner. If you want to remove the values anyway, open your browser's site data dialog for umbrellax.io and clear it; the website will continue to work normally and will simply forget your theme, language choice, and same-day article read markers on the next visit.

11. Children

The Service is intended for users aged 13 and older. In the European Union, the minimum age may be higher (typically 16) under Article 8 of the GDPR. We do not knowingly collect personal data from children below the applicable minimum age. If we discover that an account belongs to a child below the applicable minimum age, we delete the account and the associated data without undue delay. If you are a parent or guardian and you believe a child has registered for the Service in violation of this policy, write to privacy@umbrellax.io.

12. Account deletion

You can delete your account at any time. The fastest way is from inside the app: open Settings → Account → Delete Account and follow the instructions. If you no longer have the app installed, you can send a deletion request from the web. Full step-by-step instructions for both methods, an exact list of what we remove, and an honest description of what we cannot remove (copies on your contacts' devices, screenshots), are on the Account Deletion page. A shorter walk-through is also on the FAQ. After we receive and verify your request, your account and all associated information are purged immediately, with no tombstone, see section 5 for the full picture. We also cascade a delete-my-conversation command to your contacts' apps; their apps execute it automatically without further dialogs.

13. Changes and contact

We may update this Privacy Policy from time to time. If we make changes that meaningfully affect your rights or how we use your data, we will notify you in advance through the app and on our website, at least 30 days before the changes take effect. Older versions are kept on file and available on request from privacy@umbrellax.io.

For privacy questions, requests, or complaints, write to privacy@umbrellax.io or to our Data Protection Officer at dpo@umbrellax.io. For general support: support@umbrellax.io. Postal address: UmbrellaX TOO, ul. Zheltoksan, d. 1/6, korpus 3, kv. 13, 090000 Uralsk, Kazakhstan. If you are not satisfied with our response, you have the right to lodge a complaint with the data protection authority in your jurisdiction.