Privacy Policy
Last updated: 13 September 2026
SVXConnect ("the app") is a voice-communication client for licensed amateur radio operators, published by RF.Guru for Android, iPhone, iPad, macOS and Windows. It connects to user-configured SvxLink-compatible reflector servers. This policy explains what data the app handles, why, and where it goes.
The details below are written for the Android edition. The iPhone, iPad, macOS and Windows editions use their own platform's location service and permission prompts instead of Google Play services and the Android permissions in section 3.
Who we are
The developer of the app is RF.Guru (rf.guru), a trademark of Dielectricum. For privacy questions, contact privacy@rf.guru. For general support, use our contact page.
1. Data the app collects on your device
a) Identity
- Call sign — typed by the user; used to identify the operator on the reflector and to request an X.509 client certificate.
- Email address — typed by the user; included in the certificate signing request as the certificate's email address (the certificate Subject is your call sign), and used for certificate-related correspondence initiated by the reflector operator (not by us).
- Password — only for profiles that log in with a password instead of a certificate. Typed by the user and stored encrypted with a key held in the Android Keystore. The password itself is not sent to the reflector: the app answers the reflector's login challenge with a value computed from it.
b) Audio
Microphone audio is captured only while Push-to-Talk is active. Push-to-Talk can come from the on-screen button, the home-screen widget or a hardware PTT key, and the widget and hardware keys also work while the app is in the background or the screen is off. Audio is encoded with the Opus codec and transmitted in real time to the reflector you have configured. Audio is not recorded, stored, or retained on the device or by the app developer.
c) Location
- When location is enabled, the app uses Google Play services to obtain your approximate or precise coordinates. If that fails or is denied, the app may make a one-shot call to ipwho.is to derive an approximate city-level location from your public IP address. The app then looks up the city name for your coordinates with Android's geocoder, which on devices with Google Play services is a Google service.
- You can disable automatic location entirely in Settings and enter a city/latitude/longitude manually instead.
- By default ("Coarse location (grid-square center)"), the coordinates sent are the centre of your 6-character Maidenhead grid square, or of the larger 4-character square if you are within 1 km of the smaller square's centre. If you turn this off, your exact coordinates are sent. The city name and the grid locator are sent as well. The city name is not coarsened.
- The last known location and city are stored on the device and are reused when no new location is available.
- Location is sent to the reflector you have configured so that other operators can see where you are transmitting from. Location is not collected by the app developer.
d) Cryptographic material
- A private key, certificate signing request (CSR), and the certificate issued by your reflector are generated and stored locally in the app's private storage. The app sends the CSR to your reflector and presents the certificate when it logs in; the private key is not sent to the reflector. Apart from that, the private key, CSR and certificate leave the device only when you share a profile to a POC handset (see f), and then only end-to-end encrypted for that handset.
- Keys, certificates and the reflector's CA bundle are excluded from Android cloud backup and device-to-device transfer. A restored or transferred profile that logs in with a certificate therefore requests a new certificate on its first connection.
e) Application settings
- Reflector host, port, talkgroup lists, audio device choice, and other user preferences are stored locally in Android DataStore.
- This includes your call sign, email address, encrypted password, manual location, the last known location and city (see c), talkgroup and call-sign data downloaded from the reflector portal, and a list of call signs recently heard on the reflector (kept for 24 hours by default, adjustable in Settings).
- Map tiles you view are cached on the device.
The app does not collect hardware device identifiers (such as the Android ID), advertising IDs, contacts, photos, files, SMS, or call logs. When you share a profile to a POC handset, your phone's manufacturer and model are sent as its default name (section 2e). The app does not contain any third-party analytics, advertising, or tracking SDKs.
2. Where data goes
a) Your configured reflector (SvxLink-compatible server)
- Receives: call sign, email address (inside the certificate signing request), certificate-related material or a login response computed from your password, real-time audio during transmission, your location, city name and grid locator (see 1c), and standard protocol metadata (selected talkgroup, monitored talkgroups, protocol version).
- If "Auto-reconnect after a long break" is turned on in Settings (off by default), the app can also reconnect to the reflector in the background.
- The reflector is chosen and operated by you or a third party you have selected. Its data-handling practices are governed by that operator, not by the app developer.
b) ipwho.is
Used only as a fallback when on-device location is unavailable or disabled. The request consists of your outbound IP address as seen by the service. See ipwho.is for their privacy policy.
c) Reflector portal
https://portal.<your-reflector-domain>/
- The app fetches public reference data (talkgroup metadata, call-sign hints). These are GET requests for static resources and do not include personally identifying information beyond your IP address (as with any web request).
- The data is fetched about once a day while "Update from portal automatically" and "Enhanced reflector" are on, and is stored on the device.
d) Google Play services (location)
- On-device location resolution uses Google Play services. Google's privacy policy applies: policies.google.com/privacy.
- Looking up the city name sends your coordinates to Android's geocoder, which on devices with Google Play services is a Google service.
- On the other editions, location resolution uses the operating system's location service, and that provider's privacy policy applies: Apple on iPhone, iPad and macOS, and Microsoft on Windows.
e) RF.Guru pairing service
https://poc-request.svxconnect.app
- Used only if you share a profile to a POC handset: while sharing, when you open the share list or unpair or cancel a share, and at app start while an unpair is still pending. Operated by RF.Guru on Google Cloud (Cloud Run and Firestore) in the europe-west1 region (Belgium).
- Receives from your phone: the pairing code you type; a name for your phone (by default its manufacturer and model, which you can edit before sharing); platform and app version; a random token for each share, which the service stores only as a hash; a random value used for the verification number; the encrypted profile; and your IP address as part of the connection. The service also stores when the share was started, sent, accepted and ended. The handset sends its own name (by default its manufacturer, model and a short tag that the handset computes from its Android ID, which is not itself sent), app version, public key and similar values, and the service records, to within an hour, when the handset last checked in. Your phone is shown the handset's name and last check-in time; the handset is shown your phone's name.
- It cannot read the shared profile, which is end-to-end encrypted. It can see the information listed above, the size of the encrypted profile, and when requests are made.
- Retention: the encrypted profile is deleted as soon as the handset accepts or declines it, or the share is cancelled. Otherwise it is deleted with the record of the pairing attempt. A pairing attempt that is cancelled or declined is deleted 24 hours after it ends, and is first reduced to its state, reason, end time and token hashes. One not completed in time is deleted about 24 hours after its deadline (20 minutes after it starts, or at least 15 minutes after the profile is sent). The pairing code is stored only as a keyed hash, together with the pairing ID and your token hash, and deleted about 1 hour 20 minutes after the attempt starts. After an unpair, a minimal record (state, reason, end time and token hashes, no device names) is kept for 180 days. An active pairing is deleted 400 days after the handset last checked in (or was activated); checks by your phone do not extend this. Deletion is automatic and can happen up to about 24 hours after these times.
- IP addresses are used for rate limiting, in the service's memory only (IPv6 addresses shortened to their /64 network). After a failed code entry, a keyed hash of the address (IPv6: its /64 network) is stored with a failure counter for at most 2 hours; automatic deletion can take up to about 24 hours more. The service's own logs record the request type, result, timing, pairing ID and state change, but no IP addresses, tokens, codes, keys or profile content; they are kept for 30 days in Google Cloud Logging and cannot be deleted individually before then. Google Cloud's automatic request logs, which contain IP addresses, are excluded from storage.
f) Reflector live feed
wss://reflector.<your-reflector-domain>/
When a profile's "Enhanced reflector" option is on (the default), the app keeps a secure WebSocket connection to the reflector's live feed to receive node and talker status, also while it is not connected to the reflector. The app sends no data over it; the server sees your IP address and a standard connection request.
g) OpenStreetMap map tiles
When the map is shown, map images are downloaded from the OpenStreetMap Foundation's tile servers. These requests include your IP address, the app's package name (com.gururf.svxconnect) and the map area you are viewing. The OpenStreetMap Foundation's privacy policy applies.
h) DNS
To find your reflector, the app looks up its DNS SRV record with plain DNS queries to your network's DNS servers, which bypasses Android's Private DNS setting. If those servers cannot be determined, the app uses Google Public DNS (8.8.8.8) and Cloudflare (1.1.1.1). Other host names are resolved through Android's normal resolver.
i) Android backup and device transfer
If Android backup is on, Android copies the app's data to your Google account backup, and to a new phone during device-to-device transfer. This includes the settings and profiles in 1e. Keys and certificates, the share list and pairing tokens are excluded. Passwords are included only in encrypted form and cannot be decrypted after a restore, so you will need to enter them again. Google's privacy policy applies: policies.google.com/privacy.
Apart from the pairing service in (e), which is used only if you share a profile to a POC handset, the app developer (RF.Guru) does not operate a backend that receives your personal data. Data leaves the device only to the destinations listed above.
3. Android permissions and why they are requested
RECORD_AUDIO— to capture microphone audio while Push-to-Talk is active, including Push-to-Talk from the widget or a hardware key while the app is in the background.FOREGROUND_SERVICE/FOREGROUND_SERVICE_MEDIA_PLAYBACK/FOREGROUND_SERVICE_MICROPHONE— to keep the reflector connection, receive-audio playback and Push-to-Talk running with a visible notification when the app is in the background.ACCESS_FINE_LOCATION/ACCESS_COARSE_LOCATION— to determine where you are transmitting from, for display to other operators on the reflector map. Foreground use only; the app does not request background-location access.POST_NOTIFICATIONS— to display the foreground-service notification. While "Keep connection alive in background" is on, it shows the current talkgroup and the call sign of the operator talking, which Android can also show on the lock screen and pass to connected Bluetooth devices such as car systems.INTERNET/ACCESS_NETWORK_STATE— to connect to the reflector and the other destinations in section 2, and to choose the DNS servers for reflector lookups.MODIFY_AUDIO_SETTINGS— to configure the audio routing during a call.WAKE_LOCK— to keep the radio link active for as long as the app is connected, while "Keep connection alive in background" is on (the default).USE_BIOMETRIC— to ask for a strong biometric (such as your fingerprint) or your screen lock before a profile is shared to, or unpaired from, a POC handset.RECEIVE_BOOT_COMPLETED— added by Android's WorkManager library, so the optional background auto-reconnect can resume after a restart.com.gururf.svxconnect.permission.EXTERNAL_PTT— a signature permission that lets only RF.Guru's companion POC PTT helper app pass hardware Push-to-Talk key presses to SVXConnect. No personal data is involved.com.gururf.svxconnect.DYNAMIC_RECEIVER_NOT_EXPORTED_PERMISSION— added by the AndroidX library so that only the app itself can send broadcasts to its internal receivers. No personal data is involved.
4. Data retention and deletion
App data lives on your device, except where section 2 describes copies (Android backup, the pairing service, and handsets you share to):
- Settings: in the app's private storage, and in your Android backup if backup is on.
- Keys and certificates: in the app's private storage, excluded from backup and device transfer.
- No audio recordings are kept.
- Recently heard call signs: removed after 24 hours by default (adjustable in Settings).
- Shares to POC handsets: the local list and pairing tokens are kept in private storage that is excluded from backup. An entry is removed when a share attempt ends without success, when the pairing service confirms an unpair, or when you remove an ended share. A shared profile stays on the handset until it is unpaired or wiped there. Data on the pairing service follows the retention periods in section 2e. To end a pairing, unpair it in the app or on the handset. You can also ask privacy@rf.guru to delete the pairing service's records earlier. The service stores no name, email address or call sign, so RF.Guru can only find a pairing by its pairing ID. Deleting the records does not remove the profile from a handset: the handset keeps it, and stops using it after 30 days without confirming its pairing, so unpair first where possible. Log entries that contain the pairing ID are removed when the 30-day log retention ends.
To delete the app data on your device, uninstall the app, or use Android Settings → Apps → SVXConnect → Storage → Clear data. This does not delete your Android backup copy, profiles already shared to POC handsets, or records on the pairing service. Unpair POC handsets first: uninstalling or clearing data deletes the pairing tokens, and after that a pairing can only be ended on the handset. You can also reset the certificate material from inside the app: Settings → Certificates → Reset PKI.
5. Children
The app is intended for licensed amateur radio operators. It is not directed to children under 13 and does not knowingly collect data from children.
6. International transfers
Because you choose which reflector to connect to, the destination of your audio and metadata may be in a different country from where you are. Choose reflectors whose operators you trust. The RF.Guru pairing service (section 2e) is hosted by Google Cloud, with the service and its database in the europe-west1 region (Belgium); its logs are stored by Google Cloud Logging, which may keep them in other countries. The other services in section 2 (ipwho.is, Google, the OpenStreetMap Foundation and public DNS providers) may be located in other countries.
7. Security
Communication with reflector portals, the reflector live feed and the pairing service uses HTTPS or secure WebSocket. Reflector authentication uses an X.509 client certificate issued to your call sign, with the private key generated on your device and copied only to POC handsets you share the profile with; profiles can use a password instead (see 1a). The reflector protocol uses a TCP connection for control messages and UDP for audio. With certificate authentication, the control connection uses TLS and audio is encrypted, but on the first connection, before the reflector's CA bundle is stored, the app does not verify the reflector's server certificate. With password authentication, the control connection and audio are not encrypted, as defined by the SvxLink protocol.
Shared profiles are end-to-end encrypted for the receiving handset (HPKE with X25519 and AES-256-GCM). Before the profile is sent, the phone and the handset show a verification number. If the numbers match, the profile is encrypted for the handset in front of you and not for another device, including one substituted by the pairing service.
8. Changes to this policy
If material changes are made, the "Last updated" date above will be revised and the new version published at this URL.
9. Contact
Privacy: privacy@rf.guru
Support: shop.rf.guru/pages/contact