Legal
Mobile app privacy
X-Radius Operator is the phone and tablet client an internet provider's own staff use to run their network. This page is the privacy policy for that app: what it sends, where it sends it, what stays on the handset, and what it never asks for.
App record
- Application
- X-Radius Operator
- Android package
- com.app.xradius
- Apple bundle
- com.app.xradius
- Platforms
- Android, iOS
- Policy version
- 1.0
- Effective
This policy covers the operator app only. The subscriber app and the web portals are covered by the site and platform privacy policy.
The short version
Six things worth knowing before you read the rest
-
01
The app talks to your provider's system, not to ours
Sign in and every screen after it go to the server your own internet provider runs. We do not receive a copy.
-
02
No analytics, no advertising, no tracking
The app carries no analytics product, no advertising network, no crash-reporting service and no social login. There is no advertising identifier in the build.
-
03
Your sign-in is held by the operating system, not by the app
Tokens live in the Android keystore and the iOS keychain, marked so they never leave the handset and never sync to iCloud.
-
04
Every permission is asked for at the moment it is used
Camera, Bluetooth, photos and biometrics are requested by the screen that needs them, and the app keeps working when you decline.
-
05
Scans and fingerprints are read on the device and stay there
A QR frame is decoded in memory and discarded. A fingerprint or face is checked by the operating system, which tells the app yes or no and nothing else.
-
06
The app remembers your password unless you turn that off
It is saved to the device keystore when you sign in, so the account switcher can resume without a retype. The switch that stops it is in Accounts, and signing out and forgetting the account deletes it.
The data path
Two hops, and one that is not there
The app makes exactly two kinds of outbound connection. The first asks a directory host which server belongs to your licence code. Everything after that goes to that server.
There is no third path. No analytics service, no advertising network, no crash reporter, no other company.
1. Who is responsible for what
The app has one audience: staff and resellers of an internet provider that runs X-Radius. It is not an app for that provider's subscribers, and a subscriber cannot sign in to it.
That makes two organisations responsible for two different things, and the split matters when you want to exercise a right:
- Your provider decides what subscriber records exist, holds them on the server they run, and answers for them. They are the controller of that data. If you are a subscriber of an internet provider and want to know what they hold about you, ask them, not us.
- X-Radius writes the software and publishes the app. When your provider hosts with us, we hold their system on their instructions and act only on them. We are not a party to the relationship between a provider and their subscribers.
2. Where data goes
The app makes two kinds of outbound connection and no others.
Finding your provider's server
The first time you sign in, the app asks an X-Radius directory host which server belongs to the licence code you typed, and gets back its address. That licence code is the only thing it sends. No name, no password, no device identifier, no contact details. The address that comes back is checked before it is stored, and then pinned: once an account has a pinned address the directory host is not contacted again, so later sign-ins skip this step entirely.
Everything after that
Once the address is pinned, every request goes to your provider's server over HTTPS: signing in, the subscriber list you open, a payment you record, a ticket you answer, a report you run. What reaches that server is what the equivalent screen in the web portal would send, because both clients call the same interface. If your provider hosts their own server, nothing in the app reaches us at all.
Things you hand to another app yourself
Four features end outside the app, and only when you tap them: sending a router or VPN configuration file to another app, opening a one-time-password link in your authenticator, opening an external link in your browser, and paying. A card payment is not taken in the app at all — it opens the payment provider's own page in your browser, and the app is told only whether it succeeded. What happens on those pages is governed by the app or the provider you were handed to, not by this one.
3. What stays on the device
Four stores, with four different lifetimes.
| Held in | What | Removed when |
|---|---|---|
| Android keystore, iOS keychain | Your access and refresh tokens, and your password. The password is kept by default; the switch that stops it is on the Accounts screen. | You sign out and forget the account, or you uninstall the app. |
| App preferences | Settings with no secret in them: interface language, light or dark theme, the licence code and server address of the account you are signed in as, the list of accounts you have saved, each with its username and system name but never its password, and this counter's own printer and slip settings. | You uninstall the app or clear its storage. |
| App-private files | Work in progress that must survive the app being killed, such as a point-of-sale sale that has been taken but not yet confirmed, and the print queue behind it. | The work is completed or discarded, or you uninstall the app. |
| Memory only | Camera frames while a QR code is being read, and the pages you are looking at. | You leave the screen. |
The keychain entries are marked as device-only. They are readable after the first unlock of the handset and are excluded from iCloud, so a session authorised on one device is not restored onto another. On Android they are encrypted under a key held by the platform keystore; enrolling or removing a fingerprint rotates that key and the stored session is discarded, which is why a fingerprint change sends you back to the sign-in screen.
Diagnostic messages the app writes when a request fails record the method, the path, the status code and the support reference. Request and response bodies and headers are deliberately left out, because that is where the tokens and the password are. These messages stay on the device.
4. The permission ledger
Nothing here is requested at first launch. Each one is asked for by the screen that needs it, and the rest of the app keeps working if you say no.
| Permission | Where | Asked for when | If you decline |
|---|---|---|---|
| Camera | Android, iOS | You open the code scanner to look up a subscriber, or take a profile photo. | Type the identifier instead, or pick an existing picture. |
| Photo library | Android, iOS | You choose a profile picture, or attach a file to a support ticket. | The avatar stays as it is and the ticket goes without an attachment. |
| Bluetooth | Android, iOS, Windows | You pair or print to a counter receipt printer. | Printing over Bluetooth is unavailable. A network printer still works. |
| Local network | iOS | You print to a receipt printer on the shop's own Wi-Fi. | Network printing is unavailable. |
| Face ID, fingerprint | Android, iOS | You turn on the biometric lock in Settings, and then at each unlock. | The app asks for your password instead. The lock is off by default. |
| Approximate or precise location | Android 11 and older only | Never used to find you. The app declares it only because Android 11 and below refused a Bluetooth scan without it, and a receipt printer has to be found before it can be paired. | Bluetooth printers cannot be discovered on that version of Android. Nothing else changes. |
The app declares the Bluetooth scan with the flag that tells Android 12 and later it is not a way of working out where you are, and its own declaration caps the older location permission at Android 11. What matters more than either declaration is that there is no location code in the app at all: no mapping library, no geofence, and no coordinate is read, stored or sent. Nothing in it could report your position if the permission were granted.
5. Data types, in store language
App stores ask about data in a fixed vocabulary. This table answers in exactly that vocabulary, so the disclosure in each store matches this page line for line. "Collected" means the data leaves the device.
| Data type | Collected | Shared | Why |
|---|---|---|---|
| Name, email address | Yes, to your provider | No | The staff account you sign in with, and the profile you can edit. |
| User IDs | Yes, to your provider | No | Your account identifier and the licence code that names the system. |
| Phone number | Only if entered | No | A contact number on your own profile or on a subscriber record you edit, and the number a wallet top-up is charged to. |
| Photos | Only if chosen | No | A profile picture, or a file attached to a support ticket. |
| Files and documents | Only if chosen | No | An image or document attached to a support ticket. |
| App activity | Yes, to your provider | No | Actions on the account are written to your provider's audit trail, the same as in the web portal. |
| Payment information | Only if entered | No | No card number is ever entered, held or transmitted: a card payment opens in your browser and finishes at the payment provider. What the app does take is the mobile-wallet number a top-up is charged to, when that is the method chosen. |
| Location | No | No | Not read. See the note in the permission ledger. |
| Contacts, calendar, messages | No | No | Not requested. |
| Device or advertising IDs | No | No | No advertising identifier is present in the build. |
| Health, fitness, audio, browsing history | No | No | Not requested. |
| Crash logs, diagnostics | No | No | Diagnostic messages stay on the device. No crash-reporting service is included. |
Data marked as going to your provider is sent to the server they operate, under their own policy and their own retention rules. Ask them how long they keep it. "Shared" in this table means passed to a separate company for its own purposes, and nothing in the app is.
6. What the app never does
- No analytics or product-measurement service is built in.
- No advertising network, no advertising identifier, and no advertisement is displayed.
- No crash or performance reporting leaves the device.
- No social network sign-in and no social network software development kit.
- No contacts, calendar, call log, message, microphone or health data is read.
- No profile is built about you, and nothing is sold or rented to anyone.
- Nothing is read from outside the app's own storage. The media permissions that one of its components would otherwise declare are removed from the build, so the store listing cannot claim access the app does not use.
7. How it is protected
All traffic uses HTTPS. The server address returned during setup is validated before it is stored, so a fault upstream cannot redirect the app to somewhere else and survive a reinstall. The access token is short-lived and refreshed in the background; the refresh token is the only long-lived secret and it is held by the platform keystore.
The optional biometric lock puts the operating system's own check in front of the stored credential. The app never sees your fingerprint or face, only the result.
What you can see in the app is bounded by the permissions your provider gave your account. The app enforces nothing of its own here, and the server refuses what your account may not do.
8. Deleting your data
There are two different things to delete, and they are deleted in two different places.
On the device
Sign out to end the session. Choose to forget the account and the stored credential is removed from the keystore. Uninstalling the app removes everything listed in section 3. Neither action asks anyone's permission and neither needs a network connection.
On your provider's server
Your staff account belongs to the provider that issued it, not to the app. Ask them to close or delete it, the same as you would for your web portal account. They can do it from the portal immediately.
If you cannot reach them
Write to the address on the contact page with the licence code shown on the app's About screen. Where we host the system on a provider's behalf we will pass the request to them and follow their instruction, which is the only lawful thing we can do with data that is theirs. We will tell you what happened either way.
9. Children
The app is a tool for the staff of a business. It is not directed at children, it is not designed for them, and it has no content aimed at them. We do not knowingly hold data about a child through it. An account is issued by an employer to a member of staff.
10. Store disclosures
The same facts, in the form each store asks for them.
Google Play
The Data safety section is filled in from the table in section 5. Data is collected but not shared, it is encrypted in transit, and the deletion route in section 8 is the one submitted with the listing.
Apple App Store
The privacy questions are answered as data linked to you and used only for app functionality. Nothing is used for tracking, so the app does not ask for permission to track and carries no tracking identifier.
Microsoft Store
No desktop build is published yet. When one is, it is the same code making the same two outbound connections, and this policy covers it. Until then the app ships on Android and iOS only.
11. Changes and contact
Changes are published here with the date they take effect, and the policy version at the top of the page goes up. A change that widens what the app collects will be described in the app's release notes as well, so it is not possible to meet it only by reading this page.
Questions about this policy, or a request you want us to act on, go to the address on the contact page. If your question is about a subscriber record rather than about the app, your internet provider holds that data and is the right place to ask.