Privacy policy
Reliable Communications s.r.o.
In force from 31 August 2026. This is the first published version.
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
| what | why | kept |
|---|---|---|
| the account's identifier and its secret | to authenticate you when the app asks for its server list | while the account exists |
| its status and tier (free / paid) | to decide what the account is entitled to | while the account exists |
| when it was created, and by which invitation if any | to limit automated mass registration | while the account exists |
| how many devices it may use at once | the plan's limit | while the account exists |
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.
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
| account, while it exists | until deleted |
| device records | 30 days after last seen, or on request |
| connection records | up to 365 days, then destroyed |
| server-list records | 7 days — far shorter than the archive on purpose: these records name an account, and they exist only to spot enumeration of our servers, which is detected over an hour |
| account-portal session cookie | the session's lifetime |
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.
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.