Privacy policy

Reliable Communications s.r.o.

In force from 28 October 2026. Earlier versions applied from 31 August, 29 September and 24 October 2026, and two from 26 October 2026. This one says that a diagnostic report, and a history you send to support, carry a country that your device works out for itself and, from an Android phone, the code of your mobile operator (section 3.7).

1. Who this is about

The service is operated by Reliable Communications s.r.o., a company registered in the Czech Republic and a RIPE LIR. It is the sole controller for every category of data described below — your account, your devices, the connection records, and the record of which servers were named to which account. There is no second controller and no joint controller.

Its registered address is Prokopova 2856/10, 130 00 Praha 3, Czechia; its company number (IČO) is 03613607 and its VAT number is CZ03613607.

A data protection officer is appointed, and reachable at the address in section 11. No separate representative is designated: the controller is established in the Union, so one is not required.

2. What we never ask for

We do not ask for a name, a date of birth, a document, a postal address or a telephone number, and there is nowhere in the product to enter one. We do not use social sign-in. We do not ask for an email address to create an account.

An account is a random secret, generated by us and shown once. It identifies an account and nothing else: it is not derived from anything about the person holding it, and it says nothing about who that is.

Everything described below is treated as personal data, the account's secret and the connection records included, even where we ourselves cannot connect it to a person. We deliberately do not rely on the opposite argument. An address and a time can lead to a subscriber with the help of whoever assigned that address, so we cannot link it is not the same as nobody can — and a policy that turned on that distinction would be protecting us rather than you.

3. What we hold

3.1 Your account

You can delete the account yourself, at any time — in the account portal, or from the menu of any of our apps, which leads there. You confirm with the account's secret; there is no waiting period and no undo. Deleting it removes everything in this table, your devices (section 3.2), the record of which servers were named to it (section 3.4), and the time left on it, including time obtained with a coupon. Your other devices learn of it the next time they ask for a server list, and sign out. Accounts it invited keep working. If the account owns names in Lopux-Internet, the deletion is refused until those names are released or moved to a wallet you control: a name whose owner key has been destroyed could never be released or moved again, by anyone, us included.

3.2 Your devices

So that a plan's device limit can mean anything, each installation names itself with a random identifier it generates locally, and we record when it was first and last seen, and how often it was displaced by another device on the same account.

Each installation also sends a label, and the label is deliberately narrow: the model of the hardware — "Google Pixel 7", "iPhone", "macOS". A device's own name is never sent, because a computer's name is routinely a person's name, and that is the one thing this design exists not to learn.

Kept for 30 days after a device is last seen, or until you press Forget in the account portal.

3.3 Connection records

The subject of section 4. In short: for each connection made through our servers we record the address it came from, where it went, and when — encrypted at the moment it is made, kept for up to 365 days, and readable by nobody in the running system.

3.4 When we hand out a server list

We record which servers were named to which account and when. This exists to detect an account being used to enumerate our infrastructure — the attack that gets our servers blocked — and for no other purpose.

3.5 The website and the account portal

The site loads nothing from any other origin: no content delivery network, no external fonts, no analytics, no advertising, no social widgets. This is enforced by a test in our build, not merely intended, so a future change cannot introduce one quietly.

Signing in to the account portal sets one cookie. It is sealed with authenticated encryption, HttpOnly, Secure, SameSite=Lax, and carries only what is needed to keep you signed in. There is no other cookie and no cross-site identifier.

3.6 Payments

None today. Billing is not built; nothing about payment is collected, stored or processed. If that changes, this section will name the processor before any payment is taken.

3.7 The diagnostic check

The app can check whether our service is reachable from where you are, and send us what it found. This is the only thing in this policy that exists to describe a network, not a person, and it is built so that it cannot do the second.

What a report contains. For each check: which of our servers was tried and what happened — connected, refused, timed out, reset — at which stage, and how long it took; the same for a short list of well-known public sites, which is what separates our service is broken from your network blocks things; your device's platform and the app's version; what the operating system says the connection is — wired, wireless or mobile; and a country that your device works out for itself, because it decides which well-known local sites are checked. On a computer it is the country you chose on the diagnostics screen, if you chose one, and otherwise the one your time zone points to; on an Android phone, the country of the mobile operator your SIM card belongs to, and otherwise the time zone; on an iPhone, the time zone. The time zone itself is not sent, only the country it points to. The app recognises only a short list of countries this way, and anywhere else it sends no country. An Android phone also sends the code of that mobile operator, which the phone already publishes and which names an operator, not a subscriber; its first digits are the operator's country code, so it names that country wherever you are, whether the app recognises it or not.

What a report does not contain. Your device sends no account, no device identifier, no name, no location beyond that country and operator code, and no address. Every report reaches us over the internet, so our server necessarily sees the address it arrived from — that is not a choice anyone has. What is done with it is: within the request, it is turned into a country, the network operator that holds it, and a salted one-way digest of the surrounding neighbourhood — and then it is discarded. It is never written down, never logged, and never reaches anyone who reads the results.

The digest exists to answer how many different neighbourhoods does this finding rest on?, which is what tells one loud device from a real regional problem. Its salt rotates, so two reports cannot be linked across periods even by us.

The report carries a code, not your account. A random identifier generated on the device, unrelated to your account or to the device record in section 3.2, which you can replace at any time from the diagnostics screen. It exists so that a support conversation can find your own reports, and it is the only thing that connects one routine report to another.

It is on by default, and switching it off is immediate and complete. The switch is in the app. Turned off, nothing is measured, nothing is scheduled, nothing is queued, and what had accumulated on the device is deleted — not collected and withheld.

Sending is deliberately infrequent and never on a timer. A check runs when you ask for one, when the app opens, when your network changes, and otherwise at widely spread random intervals with a per-day limit. This is a privacy property rather than a performance one: traffic that repeats on a fixed beat is recognisable as ours to anyone watching the line, which is the thing the whole service exists to avoid.

Where reports go, and for how long. To a machine of ours that does nothing else, holds no account data and no key that opens anything else. The individual report is kept for 14 days, so a support question asked this week can be answered. What outlives it is counts — how many checks from a country and operator succeeded or failed, by stage, where the country is the one derived from the address and not the one your device sent — which carry nothing about any device and are what makes is November worse than September answerable at all.

Sending your history to support — only when you press the button. When something does not work, the diagnostics screen has a Send to support button. It is the one exception to everything above, and it happens only when you press it, once each time:

• It sends the history of recent checks that the app keeps on your device — the same results the diagnostics screen shows you — as one upload, separate from the routine reports. With it go the same details a routine report carries about your device: its platform, the app's version, the kind of connection, the country your device works out and, from an Android phone, the mobile operator's code.
• Pressing the button is how you ask our support for help: our support staff see your upload as soon as it arrives. The app then shows a short one-time code. Put it in the message or e-mail in which you tell us what is wrong — the code is how we know which upload is yours and whom to answer. Support sees an upload for 72 hours after it arrives; after that it is no longer shown, and nothing can be found with the code.
• Your address is included only if you tick the box for it. Beside the button is a box, off by default, that says include my address. Ticked, the internet address your device is connecting from is kept with that upload, because many network problems can only be diagnosed with it. Unticked, the upload is treated like a routine report: the address is turned into a country and a network operator and then discarded. While you are connected, the app sends a ticked upload around the tunnel, so that we see your own address rather than our server's. When it cannot — for example, because the kill switch blocks every connection outside the tunnel — the upload arrives without your address, and the app tells you so.
• The upload carries no account and is not linked to one. It is linked only to its code, and through the code to the message you send us with it.
• It is read only by our support staff, and goes to the same machine as the routine reports. It is deleted 30 days after it arrives, or earlier, as soon as your case is closed.

The address is kept only on the basis of your consent, given by ticking the box for that one upload. You can withdraw it at any time before the 30 days are up: write to the address in section 11 with the code, and the upload is deleted.

Nothing here acts on its own. Reports arrive unsigned, so nothing in our system may treat one as true: they inform a person looking at a screen and never change what the service does. A report that arrives while your tunnel is working comes out of one of our own servers, so it says nothing about where you are, and it is recorded as unlocated rather than guessed at. The country your device worked out still travels with it, as the device's own statement, and is never taken for where the report came from.

4. Connection records, in full

What is in a record

Three things and no more: the address the connection came from, where it went, and when, together with a count of how many connections that pair had in the same minute.

Where it went is recorded as our servers see it: an address when the device asked for an address, and a host name when the device asked for a name. Most requests are names.

What is not in a record

• Your account. It is not written there, and there is no way to determine which account a record belongs to — see section 5.
• Anything you sent or received. We do not decrypt, inspect or store the contents of a connection.
• Which pages you opened, what you typed, or what was shown to you. A host name is where the connection went, not what happened inside it.
• Ports, byte counts, protocols. Not collected.

Why we hold them

So that a lawful order addressed to us can be answered. Such an order asks about an address at a time — never about a customer, which is why no customer appears in the records.

The lawful basis is legitimate interest. No statute obliges us to keep these records. We keep them so that a lawful order addressed to us can be answered at all, and so that abuse of our own infrastructure can be traced — a company that can answer nothing is not thereby protected, it is simply unable to act. That interest is weighed against the rights of the people whose connections are recorded, which is why the records hold three fields and not more, why they carry no account, why they are sealed to a key the running service does not hold, and why they are destroyed on a fixed schedule.

How they are protected

Each record is encrypted on the server that makes it, at the moment it is made, using a key whose private half is not held anywhere in our infrastructure. The machine that stores a year of records cannot open a single one of them; neither can the servers that produced them.

Reading requires a person to bring that key by hand. Every reading is recorded — who did it, when, and under what authority — and that record is kept alongside the archive.

The archive is also sealed hour by hour and day by day, each day carrying the previous day's fingerprint, so that a record cannot be removed or altered afterwards without it becoming visible.

What these records will and will not show

Stated plainly because a reader may otherwise assume more than is true, in either direction:

• The system records what was open when it looked, several times a minute. Sustained contact is recorded reliably; brief contact is recorded partially. A request that finds nothing is not proof that nothing happened.
• One address is often many people. A household, an office or a mobile carrier can put hundreds of people behind a single address. A record naming an address does not name a person, and we cannot make it do so.
• For servers reached through a content delivery network, the address that reaches us is the network's and not yours — we record nothing at all for those, rather than record something misleading.

5. What we cannot do, by construction

These are not promises to behave; they are properties of how the system is built, and each can be checked.

• We cannot link a connection record to an account. The servers that carry your traffic never learn which account you are: they authenticate a shared credential, not a person. The account records and the connection records are held under different keys and share no field that could join them — the archive is sealed to a key our systems do not hold, so even complete access to everything we run yields the account records and an unreadable pile of the others.
• We cannot read the archive from the running service. No component holds the key.
• We cannot silently delete from the archive. The sealing chain makes a removal visible, and a removal made on schedule is recorded as such so that it can be told from any other kind.

6. How long we keep things

365 days is the maximum, not a commitment to keep anything that long: the operating figure is set in configuration and is shorter while the service is in trial. It is never longer than the maximum stated here.

Connection records are destroyed by deleting the day's storage, not by marking rows deleted.

7. Who else sees any of this

We do not sell, rent or share any of it. It is disclosed only in response to a lawful order addressed to us, and only what that order covers.

Our servers are rented from infrastructure providers, who act as processors. We name the categories of provider rather than the individual companies: a published list of who carries our traffic is a ready-made map for blocking the service, and our servers are deliberately spread and rotated. The current list is provided on request to anyone entitled to it, including a supervisory authority.

8. Your rights

You have the rights the applicable law gives you: access, rectification, erasure, restriction, objection, and complaint to a supervisory authority.

For your account and your devices we can exercise all of them. Those records are tied to the account you sign in with, so we can find them, show them, correct them and delete them.

Erasure you can do yourself. Deleting the account in the portal, or through the menu item in any of our apps, erases it immediately, with what section 3.1 lists. It needs the account's secret and nothing else — no name, no address, no document, because we hold none — and it works for an account we have blocked as well: a block limits what an account can do, not your right to have it erased. If you no longer have the secret, we cannot tell your account from anyone else's, and we will not delete one on the strength of a request that cannot prove it.

For the connection records we cannot, and the reason is how the system is built rather than a position we have taken. Nothing in those records names an account, and no field joins them to one, so we cannot tell which of them — if any — are yours. We will not ask you for your address in order to search by it, either. One address is commonly shared by many people, so an answer assembled that way would hand you other people's records and hand yours to whoever asked next. The property that stops us assembling a picture of you is the same one that stops us retrieving one for you on request; we would rather say so plainly than offer a search that only looks like an answer.

9. Security

Traffic between your device and our servers is encrypted. Connection records are encrypted before they are stored. Account secrets are held by us because the service must authenticate you with them; they are never shown to anyone else and never leave our systems.

If a breach affects your data and is likely to put you at risk, we will tell you, and we will notify the supervisory authority as the law requires. The archive is built so that such an event is detectable rather than assumed: every reading of it is recorded, and the sealing chain makes a removal or an alteration visible after the fact.

10. Changes

A new version is published on this page, carrying the date from which it applies. A material change is announced in advance, on the website and in the app. Those are the only two channels we have: an account has no email address and no name, so there is no way for us to write to you personally — a consequence of section 2 rather than a choice made here.

11. Contact

Questions about your data, and requests about it, go to privacy@relcom.com. That address reaches the data protection officer appointed under section 1. It is separate from general support, so that a request carrying a legal deadline is not lost in the ordinary flow of messages.