Privacy policy

1. General

1.1. This policy applies to all data the service receives when the MultiOBX website and app are used.

1.2. Provider: the owner of the MultiOBX service.

1.3. By creating a key, paying for time or using the app you accept this policy. If you do not agree, do not use the service.

2. What data is processed

2.1. Access key. When a key is created, the server stores only its digest (HMAC-SHA256 with a server secret). The key itself is not stored and cannot be recovered from the digest.

2.2. Devices. For each device attached to a key (no more than 5) the following is stored: the WireGuard public key, the address inside the tunnel, a service name from a word list, the platform type (Windows, Android, iOS) and the date it was added. The real device name is never requested.

2.3. Payment. The date until which time is paid; order numbers, amounts and statuses; voucher redemption marks. Card, account and wallet details never reach the service: they are handled by the payment provider under its own rules, and the service only receives the fact of payment and the order number.

2.4. Website. After signing in, one session cookie is set: a random identifier stored in the database as a hash, valid for 30 days or until sign-out. Your account page also sets a random device mark cookie for two years, so a shared voucher cannot be redeemed twice from one device. There are no analytics, advertising or third-party cookies. The IP address is used for rate limiting and is not stored in the database — except when a shared voucher is redeemed: then one-way fingerprints (a hash keyed with the server secret) of the network and the phone model are kept; the network fingerprint is erased after 3 hours, the phone model one after a day, and the device mark fingerprint stays with the redemption record. Web server logs containing IP addresses are kept for no longer than 7 days and are used only to protect against attacks.

2.5. Support requests. What you write yourself and the address you write from.

2.6. Failure log. To find breakage that is not visible to everyone, the service records refusals and errors: the time, what exactly failed, on which part of the site, and which "system and browser" pair from a short list, such as "iOS/Safari" or "Windows/Chrome". The full browser string is not kept: it is nearly unique and would act as a fingerprint. Ordinary page views are not recorded; this is not a traffic counter. Entries are kept for 20 days and then deleted automatically.

2.7. How failure-log entries are linked. Entries carry a short mark shared by several actions in a row: without it there is no way to tell that three refusals are one person who failed to sign in three times. The mark is a one-way function of the address and the "system and browser" pair under a random secret that lives only in the server's memory and is created anew on every restart. The secret is never stored, so the address cannot be recovered from the mark, neither by us nor by anyone who obtains the database. The mark includes the hour, so linking works within an hour rather than permanently.

2.8. What the service does not collect. Name, e-mail, phone number, identity documents, payment details. Tunnel servers keep no connection logs: who connected, when and to which addresses is not recorded. System logs on tunnel servers are kept in memory only and are wiped on reboot.

2.9. Reports from the app. The app tells the service how connecting goes: what failed on your side (a fault type from a short list — for example, the network adapter could not be created, the handshake with the server did not complete or the Tor network did not come up) and that a connection succeeded or ended (how long the session lasted and how much data passed, without addresses). A report contains: the server name, the selected route, whether censorship bypass was on, the platform and app version, the network type (Wi-Fi or mobile) and the carrier code, the support nickname if you set one, and the device number the service itself issued at registration. It contains no site addresses, no traffic contents, no access key and no IP address. A report is tied to the device number and therefore to your key — otherwise "broken for everyone" cannot be told apart from "broken for one person". Fault reports are kept as long as the fault log; reports of successful connections are kept for two days, after which only overall counters per server and route remain, with no device numbers. Everything is deleted automatically.

2.10. Telegram bot. If you sign in to our bot with your key, the server keeps your Telegram account number (a number) and username (@username, if any) — no name — together with the key number, the reminder setting and which reminders were already sent. The bot deletes the message with the key from the chat right away. If the key is created or changed in the bot, the bot sends the new key once as a message — it stays in your Telegram chat until you delete it (the “Saved it — delete the message” button); the server itself does not keep the key in plain form. “Sign out” in the bot, changing the key or “Close other sessions” on the site unlink Telegram from the key; when the key is changed in the bot itself, the Telegram account it was changed from stays linked.

2.11. Invitations. If a key was created via an invitation link, the server keeps which key invited it and the days credited for it — to give the reward. The invitation link sets a separate cookie with the invitation code for 30 days; it is erased once the key is created. The inviter sees only numbers (keys via the link, how many paid, days earned), not which keys they are.

3. Purposes

3.1. To make sign-in with a key, devices and paid-time accounting work.

3.2. To accept payment and match it with a key by order number.

3.3. To answer support requests.

3.4. To protect the service from key guessing and attacks (rate limiting).

4. Disclosure

4.1. To the payment provider: the order number and amount needed to accept payment, and for card or SBP payments also the key number (the provider requires it for its payment checks; the key number does not allow signing in).

4.2. To public authorities: only where the law directly requires it, and only the data the service holds (see section 2). The service has no data about where you connected.

4.3. To nobody else. Data is not sold and not shared for advertising.

5. Retention and deletion

5.1. The key record, devices and orders are kept while the key exists. When a key is deleted, its devices, sessions and orders are deleted with it.

5.2. A website session is deleted on sign-out or after 30 days.

5.3. To delete a key with its related data, write to support and quote an order number or the date the key was created. Do not send the key itself.

6. Data protection

6.1. Keys are stored as digests, sessions as hashes. The website works over HTTPS only. The server secret is kept in a separate file with restricted access.

6.2. The website runs no scripts and loads nothing from third-party servers.

6.3. There is no absolute protection for data sent over the internet; the service takes reasonable measures but cannot guarantee the absence of risks outside its control.

7. Your rights

7.1. Everything stored in connection with your key is visible in the account page: devices, term, orders, invitation counts; the Telegram link is shown in the bot itself.

7.2. You may delete the data (clause 5.3), change the key in the account page or stop using the service at any time.

8. Changes

8.1. A new revision is published on this page with its date. Continued use of the service after publication means acceptance of the new revision.

9. Contact

9.1. Questions about data processing: multiobx@tutamail.com.