Privacy and cookies

This notice covers two separate things: the FoxSDR application you install, and this website. They collect different data, for different reasons, and are described separately below — the application first, because that is the part that runs on your own machine. It is written to be complete rather than short: every field either of them stores is listed, including the ones most notices leave out.

The application: what it sends

There is no account, no licence key and no activation, and FoxSDR never reports anything about what you listen to. It makes exactly four kinds of network request on its own account: an update check; an anonymous usage report, with a small “still running” beat while the application is open; a crash or freeze report after a fault; and — only when you open the plugin store or press CHECK NOW in it — a request to the plugin catalogue. Each is described below, field by field, and each can be switched off. Three switches govern them: SYSTEM → Updates, SYSTEM → Usage reporting and SYSTEM → Diagnostics. No feature depends on any of them being on, and nothing nags you for turning one off.

What stays on your machine

Your recordings, both audio and raw I/Q, the images SSTV and weather-satellite decoders build, everything the decoders decode, your bookmarks, band plans, settings, your receiver position and your installed plugins are files on your own disk. Nothing uploads them, and no frequency you tune to leaves your machine.

The update check

Once per launch the application asks this site whether a newer version exists. The entire request is GET /api/update?v= followed by the version you are running — no identifier, no install id, no cookie, and nothing that could be tied to a later request. This server writes no analytics record for it: only page views and file downloads are recorded, and the update endpoint is neither. Turn it off under SYSTEM → Updates, and the application never contacts the service again.

The answer can also carry a short message from us to people running an older version — for example, telling you a release fixes something worth updating for — shown in the same update banner as the version notes. Nothing extra is sent or recorded to make that possible: it rides in the same request above, on the same schedule, under the same switch.

Nothing is downloaded or installed unless you press the button. If you do, the installer is fetched from this website over HTTPS and its SHA-256 is checked against the digest the server published before the file is given a name anything could run — and that fetch is an ordinary download from this site, so it is recorded like any other, with the IP address, approximate location, browser and operating system described in the website half of this notice.

A copy installed from the Microsoft Store asks the Microsoft Store instead, never this site (since FoxSDR 0.99.53). Once per launch, when SYSTEM → Updates → Ask the Microsoft Store for updates at startup is ticked, FoxSDR asks Windows' own Store service whether it has a newer package for this copy. Nothing of FoxSDR's is sent in that request — no version, no identifier: Windows identifies the app to Microsoft by the package identity it already holds, as it does for the Store's own background updates. The answer stays in the application. Nothing is downloaded or installed unless you press Install from the Microsoft Store and confirm the dialog Windows shows; the download and install are then Microsoft's, under Microsoft's privacy statement. Untick the box and the Store is not asked.

Usage reporting

From version 0.53.0 there is an anonymous usage report, under SYSTEM → Usage reporting. It is on by default, and you can turn it off — untick that box and reporting stops immediately. One report is sent per launch, describing the session that just finished, and this is the whole of it:

That is the complete list. It ships with the application as PRIVACY.md, and an automated test asserts the payload field by field, so a new field cannot be added without that test failing and both documents being updated. Turning reporting off deletes the install identifier, so if you ever switch it back on you get a new one that cannot be linked to the old.

The report is sent at start-up, describing the session that has already finished, and never at exit — a network call on the way out can hang an application somebody is trying to close, and a report written at exit would be lost by the one event most worth counting. Nothing in the reply is read or acted on.

Failure counts, in full (from FoxSDR 0.99.64). The field is a short text of kind=count pairs, such as radio_fail.rtlsdr.busy=2 — an RTL-SDR that would not open, twice, because another program had it. FoxSDR builds each kind from a fixed table and sends nothing that is not in it, and the receiving server discards anything that is not in the same table. Where a reason is read off what a driver said, FoxSDR picks one word from a fixed list and throws the sentence away. So that a failure in a session that then crashes is still reported, the counts wait in a small file named telemetry-health beside your settings file, together with your install identifier, until the server has accepted a report that carries them; switching usage reporting off removes the file.

Slow frames and recoveries, in full (from FoxSDR 0.99.65). They are in the same field and the same kind=count form. slow.rail.250ms=3 is three frames of the window that each took a quarter of a second or more, in the part of drawing it that is the menu column. The part is one of eighteen words, events, frame-start, pre-draw, plugin-panels, toolbar, rail, spectrum, patch, status, dialogs, polls, saves, render, present, recorder, plugins-reload, startup, other, and how slow it was is one of three: 250ms for a quarter of a second to under a second, 1s for a second to under five seconds and 5s for five seconds or more. Time you spent answering a Windows prompt, or dragging or resizing the window, is taken out and never counted. recovered.audio=1 is one time that FoxSDR met a fault and carried on by itself. The word is one of thirteen places, audio, reopen, srcthread, vendorcall, ringdrop, dspexc, cfgsave, enumchild, pluginapi, webroute, patchload, sdrenum, sdrlost, in this order: the sound output stopped and the watchdog restarted it; a SoapySDR radio driver faulted and FoxSDR reopened the radio by itself; a radio driver never returned from a read when the receiver was stopped and FoxSDR let the thread go; a call into a SoapySDR vendor module did not return in time and was let go; the radio delivered samples faster than they were taken off and some were dropped; the signal-processing thread threw an error that was caught and the receiver stopped; the settings file could not be written; the helper that lists SoapySDR radios died and was contained; a plugin call into FoxSDR threw an error and was answered with a default; a web-interface handler threw an error and the server answered with a failure; a saved patch loaded with connections left out; the SDRplay service did not answer a scan and the scan was let go; the SDRplay session was lost and SDRplay is shut for the rest of the session. FoxSDR builds each one from a fixed table and sends nothing that is not in it, and the receiving server discards anything that is not in the same table, so there is never a device name, a serial number, a path, a frequency or any message text; a report carries at most the eight worst kinds of slow frame and eight kinds of recovery. They are counted under the same two switches as the failure counts, only while both Usage reporting and Diagnostics are on, they wait in the same small file named telemetry-health beside your settings file until the server has accepted a report that carries them, and switching usage reporting off removes the file.

The “still running” beat

A report that arrives when the application starts can say who launched it and never who still has it open. So, while FoxSDR is running — and only while usage reporting is on — it also sends one very small message every five minutes, carrying three fields and nothing else:

Nothing from the session rides along: no modes, no panels, no radio model, no durations, no counters. Beats are written to a dataset of their own, kept apart from the session reports, so no usage figure changes meaning. The same switch stops both: the sender refuses to arm without a valid install identifier, and switching usage reporting off deletes it, so off means no beats at all. A beat still in flight when the next one is due is skipped rather than queued.

Where the usage reports go

To a Cloudflare Worker operated by this project at https://telemetry.foxsdr.com, which writes the counters above to a Cloudflare Workers Analytics Engine dataset. Cloudflare processes it on our behalf and stores it for three months, after which it is gone. Nobody else receives it, it is not sold, rented or shared, and the only thing read back out of it is aggregate counts, through the same password-protected dashboard described further down. The Worker's source is published with the application, so you can read what the receiving end does. Crash reports do not go here — they go to this site's own server, described next.

Crash and freeze reports

If FoxSDR crashes, or stops responding, it writes a report describing the fault to %LOCALAPPDATA%\FoxSDR\crashes\ on your own machine, and sends the report text on the next start — never from inside the failure itself, because a program that has just faulted cannot safely open a network connection. It goes to POST /api/crash on this website — not to Cloudflare, and not to any third party — and it is anonymous: there is no account, no licence key and nothing to sign in with.

The switch is SYSTEM → Diagnostics, and it governs the writing and the sending equally: with it off no report is written, no directory is created, and no connection is ever made. It is a different switch from usage reporting. Turning usage reporting off does not stop a crash report — it empties the install-identifier field in one, because then no identifier exists and a crash report never mints one (see the last row of the table below). Until this release the notice above named the wrong switch; the software has always used Diagnostics, and the two now say the same thing.

This is the whole of what a report contains:

Corrected in FoxSDR 0.99.33. Before 0.99.33 the scrubbing described above was applied only to the radio driver's lines, not to the application's own, and a few of the application's own lines could therefore reach a crash or freeze report carrying the frequency you had asked for or were transmitting on, a patch radio's label (which can include its serial number), the names you gave patch parts, the first line of text a decoder on the patch page had produced, and the list of USB devices the USB driver printed, including their serial numbers. That contradicted this notice. From 0.99.33 every line is scrubbed before it leaves your computer, and those log lines no longer contain those values in the first place.

Corrected in FoxSDR 0.99.59. This notice has always said that a crash report carries no machine name and that the application never sends your IP address, but until 0.99.59 the scrubbing did not look for network addresses or host names. A few log lines could therefore reach a crash or freeze report, or the diagnostics log of a bug report, carrying the address or host name you typed for a network radio such as an ADALM-Pluto, or an address or web address that a network radio driver logged; they could also carry the number of a serial port and, on a few error lines, the name of a sound card. That contradicted this notice. From 0.99.59 addresses and host names are replaced and serial-port numbers masked as described above, the ADALM-Pluto's own lines no longer print its address, and no log line names a sound card.

A crash report carries no frequency, nothing decoded, no file path, no user name, no machine name, no network address and no location. Reports are held on this site's own server, behind the same password-protected dashboard as everything else, and are kept for 90 days after the fault was last seen, then deleted — the same three months the usage reports are kept for. The first report of any one fault is kept in full, along with one further report per build the fault survives into, up to three; every other report of that same fault is counted rather than stored. An automated test holds both what the endpoint accepts and what it writes to disk to the table above, in both directions, so a field cannot be added to either without this table changing too.

A full memory dump is never sent, under any setting. A memory dump is a copy of the program's memory and can contain file names, window titles and received signal data. It is off by default; if you switch it on under SYSTEM → Diagnostics a .dmp is written beside the text report, locally only, and the uploader opens files named crash-*.txt and hang-*.txt and nothing else.

A sentinel report, from FoxSDR 0.99.64. Some endings nothing inside FoxSDR can report: a crash that skips every handler, a stack overflow, a window frozen so hard that the freeze watchdog is stuck too. So, in an interactive session with Diagnostics on, FoxSDR starts a second copy of its own program, with no window, that only waits for the first to end — the sentinel. It can read how FoxSDR ended (its exit code, and when it started and stopped), a small shared page of numbers that FoxSDR keeps up to date (which stage it is in, how many frames it has drawn and when it last drew one, which part of drawing the window is under way, whether a menu is open or the window is being dragged), and the end of the session log, scrubbed like every other report’s. It reads none of FoxSDR’s memory and takes no dump, and the page of numbers has no room for text, so it cannot hold a name, a path, a frequency or an address. When FoxSDR ends, the sentinel writes one report in the same folder and format as the others — none if FoxSDR ended normally or had already written one — whose reason is made of fixed words and whole seconds, with the receiver lines replaced by a fixed sentence saying it cannot read them. It sends nothing itself: its report goes out on the next start, under the same switch and the same limits as every other, and only if FoxSDR crashed, if its window had stopped drawing, or if it ended before the first frame. An ending from outside (Task Manager, or a script) and an ending as Windows closed your session stay on your machine and are never sent. With Diagnostics off the sentinel is not started.

How often. At most five reports a day from one machine, and the same fault only once a day however many times it happens — both limits are kept in your own settings file, so a machine in a crash loop stops sending on its own rather than being told to, and a report that fails is retried on later starts at most three times and then left alone. Turning an offset in a report back into a function name needs the debug database from that exact build, which stays on our own machines and is never uploaded anywhere: the resolution happens locally, not on the server.

What the application never sends

• Frequencies you tune to. What somebody listens to is the most sensitive thing this software knows, and it is never collected. In the United Kingdom, intercepting a message you are not authorised to receive, or disclosing its contents, is an offence under section 48 of the Wireless Telegraphy Act 2006.
• The names or paths of files you open. A recording's file name is your own data — it can name a service, a place or a frequency. When an I/Q file fails to reopen, the log records that it did not reopen; the name stays on screen, where you already know it.
• Anything decoded — pager messages, aircraft, vessels, images, satellite traffic.
• Your position, or the position of anything you receive — including the receiver position you set, which is never transmitted in any report. See below.
• Your IP address, or any location derived from it. A request necessarily reaches a server from an address, because that is how the internet works; the usage endpoint reads no connection information and writes no request logs. From FoxSDR 0.99.59 a network address or host name in the log lines a report carries is replaced by <host> as well.
• Hardware serial numbers. The radio model is useful; the serial identifies your individual radio, and is removed before sending.
• Your name, your machine's name, your user account, any file path, or the name of a sound card.
• A full memory dump.

The receiver position, and the GPS

FoxSDR needs to know where the receiver is, because every range and bearing on the map and the radar scope is measured from it. You can type it, click it on the map, or read it from a GPS receiver on a serial port.

The position stays on your machine. It is stored in your own settings file and is never transmitted — not in the usage report, not in the beat, not in a crash report, not anywhere. Reading it from a GPS is something you start: you name the port and press “Read position from GPS”. The port is held only until the first fix arrives, and for at most 60 seconds. The diagnostic log records the port name, the baud rate, sentence and satellite counts and any error — never the position, and never the text of an NMEA sentence. A port field containing something that is not shaped like a port is logged as its kind and length (“a typed device path, 27 chars”), so a file path with your user name in it cannot ride into a report. Two automated tests hold this: one against the log ring, and one against the log file the real application wrote.

The plugin catalogue

The catalogue is contacted when you open the plugin store window (the first time in a session, since FoxSDR 0.99.16), whenever you press CHECK NOW in it, and when you choose to install something. Nothing is fetched at startup, the window does not reopen by itself, and no plugin ever updates itself. The catalogue is a file published on GitHub (raw.githubusercontent.com), so that request reaches GitHub's servers, which — like any web request — see the address it came from. No identifier of yours is sent with it: no install id, no cookie, nothing that could be tied to a usage report. Every download is HTTPS, size-capped, refused on a cross-host redirect, and verified against the sha256 published in the catalogue before it is allowed to become a file. The source is a setting: you can point it at a different catalogue, or at an index.json on your own disk, in which case no network request is made at all.

Plugin sites you add

From FoxSDR 0.99.74 you can add other people’s plugin catalogues, called plugin sites, and each one you add is one more address the application contacts. Only you add one: press SITES in the plugin store’s top bar, paste an address, and tick the box that says FoxSDR has not reviewed the site. FoxSDR adds nothing, and contacts nothing, on its own. A site is read at the same two moments as the public catalogue — the first time you open the store in a session, and whenever you press CHECK NOW — and is given a few seconds to answer. The request carries the address you gave and nothing else from FoxSDR: no identifier, no cookie, and a client name (cascade-plugin-repo/1.0) that is the same for every copy. So the site sees your IP address, as any web server does.

A site’s plugin files and pictures are fetched only from the same host as its catalogue, and only when you press GET or UPDATE on one of its plugins or open its page. Each site’s catalogue is kept, unchanged, in the plugins folder on your own disk, read back at start-up and deleted when you press REMOVE on the site; the addresses themselves are in your settings file. The failure counts for the plugin catalogue and for plugin installs (see usage reporting above) are the public catalogue’s: a site that cannot be reached, or one of its plugins that fails to install, is not counted.

Plugins offered in some countries only

Some plugins are offered only to connections from certain countries. When the application fetches the plugin catalogue it also asks this website for a short regional list, and a plugin on that list is downloaded from this website rather than from GitHub. To decide what to answer, the website reads the two-letter country code that Cloudflare passes along with the request (CF-IPCountry), which Cloudflare works out from the address the request comes from. The country code and the address are used for that one answer and are not stored, no identifier of yours is sent, and these requests are not recorded in the analytics of this website. A connection whose country cannot be told, or one arriving through Tor, gets an empty list. A VPN changes the country the website sees. The regional list is not asked for when you have pointed the store at a different catalogue.

A plugin that can transmit

From FoxSDR 0.99.74 a plugin can ask to send audio through your transmitter; the plugin store and the Fitted modules window then show it as “Can transmit through FoxSDR”. It can key the transmitter only if you pressed GRANT TRANSMIT on its page and armed the TRANSMIT page for 5, 15 or 60 minutes. The grant is stored in your own settings file by the plugin’s file name and is never sent anywhere; the arming window is never stored at all. The diagnostic log on your machine records the keying — tx: armed 15 min, tx: plugin <name> keyed, tx: plugin <name> unkeyed (<why>) and tx: disarmed (<why>) — as the plugin’s declared name, a reason from a fixed list and a number of minutes, never a frequency, and those lines are scrubbed like every other log line when a report or a diagnostics bundle is put together. FoxSDR’s own reports have no field for any of it.

Satellite element sets

The satellite plugin keeps its orbital element sets current by fetching them from the sources named in its satellite.cfg, every twelve hours while it is loaded. This site keeps a copy of those element sets at GET /tle/all.tle — CelesTrak’s stations, amateur and weather groups plus NOAA 15, 18 and 19, refreshed here every twelve hours — and Satellites 1.0.4 and later fall back to this file on their own whenever every source in satellite.cfg fails, so that a machine CelesTrak refuses can still track them. The file does not have to name this site for that to happen; a line reading fallback-url none in it switches the fallback off, and refresh-hours 0 switches off all fetching. The request carries no identifier, no install id and no cookie, and this server writes no analytics record for it — as with the update check, only page views and file downloads are recorded, and the mirror is neither. The element sets themselves are CelesTrak’s (celestrak.org) and every response says so.

Aircraft registry lookups

The optional Aircraft Info plugin shows who each aircraft on the map is — its registration, type and operator. The application never makes this request; installing that plugin is what enables it. From version 1.1.0 the plugin asks this site first, at GET /api/aircraft/<address>, and sends only the aircraft’s six-hex-digit ICAO address — the number the aircraft itself broadcasts — with no identifier, no install id and no cookie. Each airframe is asked about once and the answer is kept on your own machine, so it is not asked again. Only when this site does not know an aircraft, or cannot be reached, does the plugin ask api.adsbdb.com, a free third-party service, as earlier versions always did. The set of aircraft a receiver hears is a rough indication of where it is, which is why the plugin is optional and says so before you install it.

What this server keeps about a lookup: nothing per request. No analytics record is written, and neither the aircraft address nor the address the request came from is logged. The only record is five running totals since the server last started — lookups, found, not found, malformed and rate-limited — which the dashboard shows. To stop anyone copying the table wholesale, each connecting address has a lookup allowance held in memory, exactly as the other endpoints here do, and never written to disk; it is forgotten when the server restarts or when more than ten thousand addresses are being tracked, whichever comes first.

The answers come from the OpenSky Network aircraft database (opensky-network.org): for each airframe its registration, type designator, manufacturer, model and, where recorded, its operator. OpenSky offers that database as is and asks users to cite: Matthias Schäfer, Martin Strohmeier, Vincent Lenders, Ivan Martinovic and Matthias Wilhelm, “Bringing Up OpenSky: A Large-scale ADS-B Sensor Network for Research”, in Proceedings of the 13th IEEE/ACM International Symposium on Information Processing in Sensor Networks (IPSN), April 2014. The registered owner recorded there is not copied to this site or served by it, because for a private aircraft it is a person’s name; only the operator, which is an airline, air force or company, is.

The browser interface

FoxSDR can serve its interface over HTTP to other machines on your own network. It is off by default and bound to your own machine until you change it; a password is required for any binding beyond that, and without one the wider bind is refused rather than opened. Passwords are stored hashed (PBKDF2-HMAC-SHA256) and sessions are revoked whenever the settings change. There is deliberately no TLS, because the application links no crypto library and will not claim transport security it cannot provide — put a reverse proxy or a private tunnel in front of it, and never port-forward it directly. Anyone you give access to can see and control what the receiver is doing.

Feature requests sent from the application

The application has a “Request a feature” box, on its main page, where you can type what you would like it to do and press Send. Nothing is sent until you press that button, it never happens automatically, and a request that fails to reach us is not queued or retried in the background — what you typed stays in the box, in memory only, for you to press Send again, and it is never written to the configuration file or the log. This is the whole of what one request carries:

It goes to POST /api/feature-request on this website. Your IP address is used only to hold the sending rate to something reasonable, and it is never written to disk — the record actually kept is your message, your contact address if you gave one, the application version, the platform, the architecture, and your approximate country when our lookup can supply one from the connection, and nothing else. It is read by the project maintainer on the admin dashboard behind the same password as everything else here, and is kept until it is deleted from that dashboard, or until you ask. A request that has been dealt with — added to FoxSDR, or answered some other way — may be archived there rather than deleted, so the project can keep track of what was asked for and what was built; an archived request is still held, with everything listed above. If you gave a contact address and want the request deleted, write to the address below and quote enough of what you sent for it to be found.

Bug reports and dislikes sent from the application

Directly under “Request a feature” the application has a “Report a bug / dislike” box, where you say either that something is broken or that something is there you do not like, and press Send. It works exactly like the feature-request box: nothing is sent until you press that button, nothing is queued or retried in the background, and what you typed stays in memory only — never in the configuration file, never in the log. It is not a crash report, though the diagnostics log described below is put through the same scrubber and can carry some of what a crash report does. This is the whole of what one report carries:

From FoxSDR 0.99.69 the diagnostics log also carries one more line, naming by file name only (never a folder or a version) the other programs’ components that are loaded into FoxSDR — an overlay or a hook another program put there; it is the same list the crash report table above describes, and it is also part of the crash or freeze report FoxSDR sends by itself.

It goes to POST /api/problem-report on this website. Your IP address is used only to hold the sending rate to something reasonable, and it is never written to disk — the record actually kept is whether it was a bug or a dislike, your message, your contact address if you gave one, the application version, the platform, the architecture, your approximate country when our lookup can supply one from the connection, and the diagnostics log if you left it attached, the kind of any report recognised in your message (above), and nothing else. It is read by the project maintainer on the admin dashboard behind the same password as everything else here, and a report is kept until it is deleted from that dashboard, or until you ask. A report that has been dealt with — fixed in FoxSDR, or answered some other way — may be archived there rather than deleted; an archived report is still held, with everything listed above. If you gave a contact address and want the report deleted, write to the address below and quote enough of what you sent for it to be found.

The website: what is recorded when you visit

A record is written for each page view and each download whether or not you accept cookies. This is first-party analytics: the data stays on the server that serves this site, it is not shared with an advertising network, and there is no third-party script on the page.

What is deliberately not done

• No browser fingerprinting: no canvas, audio, font or WebGL probing, and nothing that tries to re-identify you after you have declined.
• No third-party trackers, advertising pixels, social widgets or analytics services. Nothing on this page loads from another domain.
• No attempt to read your clipboard, your battery, your camera, your microphone, your saved passwords or your browsing history — none of which a download page has any business with.
• Your data is not sold, rented or shared with anyone. The only outbound request the server makes about you is the IP-to-location lookup described above.

Interface designs you publish

This site can keep a FoxSDR interface design — a .foxui package — that you choose to publish. Nothing is sent until you press Publish, and it goes to POST /api/gui/publish. What is kept is what the package holds: the design itself, the name, version and description you typed, an author name if you typed one, the time it was published and a random identifier. Your IP address is used only to hold the publishing rate to something reasonable, and it is never written to disk. A published package is not listed anywhere; anyone who has its link can download it. It is kept until it is deleted from the admin dashboard, or until you ask — write to the address below and quote its link.

If you sign up as a beta tester

Apart from publishing an interface design (above), the beta form and the news sign-up are the only places this site asks you for anything. Submitting it stores your email address, and whichever of these you chose to give: a name or callsign, your platform, the radio you plan to use, your notes, and the list of features you volunteered to test. Alongside it we keep the same visit context described above — approximate location, network, browser and operating system — because a bug report reads very differently depending on the setup it came from.

• The address is used for one thing: contacting you about beta builds and what to test. No newsletter, no marketing, and it is never passed to anyone else.
• Nothing happens until you confirm. Signing up sends one email with a six-digit code, which you type into the page to confirm the address is yours. The code works for 30 minutes and is refused after five wrong tries. Until it is entered, the entry is inert: you are not on the tester list, you are not counted, and nothing further is ever sent. If somebody else typed your address in, ignore that email and the entry never becomes real — there is nothing to unsubscribe from and no action you have to take. That one message is the only automatic mail a sign-up can produce.
• If you wrote to us, we may invite you. Somebody who has written to us and left an address — through the application's feature box, for instance — may get one personal invitation from us, with a one-time link that opens this site's Confirm key. That invitation is held as a pending entry exactly like an unconfirmed sign-up: you are not a tester and not counted unless you press Confirm, and if you ignore it we do not write to you again. A pending entry does not expire on its own; it is deleted when we clear it from the list or when you ask, by one email to the address below.
• After you confirm you get your private management link, and we write when a build lands that needs what you offered to test. That is a person writing to you, not a mailing list. If you lose the link, we can issue you a new one: the old link stops working at once, the new one is emailed to you, and we keep the time that was done and whether the email went.
• That email goes through Apple. Mail for foxsdr.com is carried by Apple's iCloud Mail service, so your address and the message pass through their servers on the way to you, under their terms as our mail provider. Nothing else about you is sent to them.
• It is kept apart from the analytics. Sign-ups live in their own file, readable only by the account running the server; the analytics log records that a sign-up happened and how many features were picked, never who. An automated test fails the build if an address ever reaches the analytics log.
• Signing up again with an address already on the list does not change that entry. Changes are made from your own tester page. Instead, the address is sent one email: its private link if it has confirmed, or a new code if it has not, and never more than once in 15 minutes.
• We keep a copy of what we sent you. Every message this site sends a tester — the confirmation, and each message about a build — is kept with its text, so we can see what was said and whether it arrived. The copy is filed against your internal id, not your address, and the personal parts of it (the confirmation code or link, and your own management link) are removed before it is stored, so a kept message can never be used to act as you. These copies are deleted with the rest of your entry when you leave.
• Messages between you and us are kept. The Messages box on your tester page is a conversation with the person building FoxSDR: what we write to you and what you write back, each with the time it was written and, if you chose one, which of your reports it is about. It is filed against your internal id, not your address, and only you (with your private link) and we can read it. We also note when you have had our messages on screen, so we know they reached you. While your page is open it asks for new messages every few seconds, so they appear as they are written, and it says how long ago you last used it; while it keeps asking, and half a minute after, and only if you used it in the last five minutes, the server knows you are there. That is held in its memory only, never written down. We do not email you for each message: when we write while you are away, you get one short email saying a message is waiting, with your link and without the message itself. No other such email follows while that message is unread, for up to 12 hours, nor within half an hour of the last; and if you were on the page when we wrote but have not seen the message ten minutes later, the email goes then. A copy of that email is kept as described above; when you write, no email is sent anywhere. The conversation is kept until you leave or ask us to delete it, and leaving deletes all of it.
• Kept until the beta programme ends, or until you ask. One email to the address below removes you and deletes the entry — you do not have to give a reason.
• The lawful basis here is your consent, given by ticking the box; the form does not submit without it.

If you are a beta tester and enter your tester code in FoxSDR

Your tester page (above) gives you a private management link and, from it, a tester code you can enter into FoxSDR itself, in SYSTEM → Tester code. Doing that is different from the anonymous usage reporting described above: usage reporting cannot be traced back to you, on purpose, while a session reported under your tester code is linked to your tester entry by design — that is the whole point of it, so we can see which features and plugins the people actually testing them have tried. It is off unless you enter a code, and the field is blank by default.

Link FoxSDR on your tester page gives FoxSDR a separate app code, so your private link never has to be entered into the application. The app code can do two things only: send the session reports described below, and send and read the messages in your Messages box. It cannot see your address, change your entry or remove you. It is kept with your tester entry; pressing New link cancels it, after which FoxSDR has to be linked again, and leaving the programme deletes it with the rest of your entry.

While a code is entered, roughly once per session FoxSDR sends this, and nothing else:

• What is stored is your tester id (never your code or address), the time the report was accepted, the session start reported above, the version, the platform, the session length, and the features, plugins and radios named above — one line per accepted session, kept for up to a year and then removed automatically, counted from when the session actually started, not from when the report reached this server.
• What is shown publicly is a count, never a name. A plugin's card on the home page gains a small “tested by N beta testers” note once its current published version has been used by at least two distinct testers for at least ten minutes between them — below that, nothing is shown at all, and no page anywhere lists who any of those testers are. The counts on your own tester page and in the admin dashboard are the same underlying figures read in more detail; testers are never named to each other.
• Your IP address is used only to hold the sending rate to something reasonable, and it is never written to disk.
• How to stop it: clear the tester code out of FoxSDR's settings, and nothing further is sent. You do not have to leave the beta programme to do that.
• Leaving the programme deletes it. Removing your entry, from your tester page or by asking us, erases every session report already on file for you along with the rest of your entry — the same erasure the rest of this section describes, applied to this data too.
• The lawful basis is the same consent that covers the rest of your tester entry: entering the code is an action you take, and nothing is sent without it.

If you sign up for news by email

The news page asks for one thing: your email address. It is kept so we can email you when there is a new version of FoxSDR, and now and then about what is being built. It is used for nothing else and never passed to anyone.

• Nothing happens until you confirm. Signing up sends one email with a six-digit code to type into the page. Until it is entered, nothing else is sent, and an address that has not confirmed within a week is deleted - by code that runs on the server every day. If somebody else typed your address in, ignore that email.
• Every email carries a link that takes you off the list in one press. Leaving deletes the address from the server's file, together with the copies we kept of what it was sent; nothing about it is kept.
• It is its own list. A news subscriber is not a beta tester: the address is kept in a separate file, readable only by the account running the server, and is not counted or shown as a tester. If you are also a tester you get each message once.
• We keep a copy of what we sent you, filed against an internal id rather than your address, with the confirmation code and unsubscribe link removed, exactly as for testers.
• That email goes through Apple, as described for testers above.
• The analytics log records that a sign-up happened, never who.
• The lawful basis is your consent, given by ticking the box; the form does not submit without it.

Cookies

If you decline, no identifying cookie is set. Visits are then grouped by a daily-rotating hash of your address and browser, which distinguishes visitors for counting purposes and is not usable to follow you between days or between sites. You can change your mind by clearing this site's cookies and reloading.

Which language you see

The pages can be shown in languages other than English. Which one you get is decided on the server for each page you ask for, in this order: a language you picked yourself (the foxsdr_lang cookie above, or ?lang= in the link); otherwise the languages your browser says you prefer, from its Accept-Language header; otherwise the main language of the country your connection comes from, which Cloudflare, the network in front of this site, passes along with the request as a two-letter country code (CF-IPCountry); otherwise English. Nothing is stored to make that choice: the header and the country code are read for that one response and not kept for it. They are the same two things the table above already lists as recorded with every page view, where the country code is used when our own address lookup has no answer. The translations are made by machine, and on this notice and the licences the English text is the one that binds.

Why, and on what basis

The purpose is narrow: knowing how many people find this project, roughly where they are, what they run it on, and how many go on to download it. That is what decides whether the work continues and what gets built next.

The server-side records are kept on the basis of legitimate interests in understanding and securing the site. The browser-reported detail and the identifying cookies are kept on the basis of your consent, which is why they are behind the banner and why declining costs you nothing on this site.

How long it is kept, and who sees it

Records are held for 24 months and then deleted. They sit in a file on the server behind a password-protected dashboard that only the project maintainer can open. There are no other recipients and no transfer to a third country beyond the IP lookup already described.

Two things are kept for less. Crash and freeze reports are deleted 90 days after the fault they describe was last seen, and the usage reports Cloudflare processes are deleted after three months. Each of those periods is enforced by code that runs on the server every day, not by anybody remembering to do it.

Your rights

If you are in the UK or the EU you can ask for a copy of what is held about you, ask for it to be corrected or erased, or object to it being collected at all — including the server-side records that do not depend on consent. The practical identifier for finding your records is your IP address at the time you visited, so please include it and roughly when you visited.

For the application, the controls are in the software itself, and there are three:

• SYSTEM → Usage reporting stops the usage report and the five-minute beat, and deletes the install identifier. Turn it back on later and you get a new identifier that cannot be linked to the old one.
• SYSTEM → Diagnostics stops crash and freeze reports being written or sent.
• SYSTEM → Updates stops the update check (in a Microsoft Store copy, the question to the Microsoft Store).

The reports hold nothing that can be connected to you, so there is nothing to request access to; if you want an install identifier removed from reports already sent, write to the address below and quote it, and it will be deleted.

Children. FoxSDR is a technical instrument for radio hobbyists. It is not directed at children, it collects no personal information from anyone, and it therefore collects none from children.

Write to [email protected]. You can also complain to the Information Commissioner's Office (ico.org.uk) if you think this has been handled badly.

Last updated 28 September 2026, against FoxSDR 0.99.42 — the build this site currently offers, and the one every statement above was checked against in its source. FoxSDR is published by Steven Fox; write to the address above with any question about this notice or to have an install identifier deleted from reports already sent. If this notice ever stops matching what the software does, the software is wrong — the website's collection is implemented in store.go and app.js, both readable in the site's own source, and the application's own list ships with it as PRIVACY.md with a test holding the payload to it.