Security and privacy
Your readings are yours
A monitoring tool sees everything on a machine, so it has to be careful with it. This page explains, in plain terms, what stays on your machines, what the relay can and cannot see, and how terminal sessions and packet capture are protected. It applies to 4.0 and 3.3 alike, with differences noted.
By default, nothing leaves the machine
Readings, history, process lists and the network map are stored on the machine that recorded them, in your own user folder. Moxon Metrics makes no outside connections except these, each of which you control:
- Public IP lookup (api.ipify.org, every 15 minutes) for the Network tab. It can be switched off in Settings → Network.
- Latency checks: a few pings to your router and to a target you choose (1.1.1.1 by default).
- Alert channels you set up: ntfy, Telegram, your email server, and in 4.0 your SMS or WhatsApp provider (Twilio, Meta or the web address you enter).
- Sharing and the relay, only after you switch them on.
There are no accounts to create for local use, and no usage statistics are collected.
Sharing on your own network
- Off until you switch it on. When on, the machine serves a read-only page over HTTPS, protected by a random access key.
- The HTTPS certificate is made on the machine. When you add the machine to another one, its fingerprint is pinned: if the certificate ever changes, the connection is refused and you are told, rather than silently trusted.
- "New key" invalidates every existing link and Prometheus scraper at once. Repeated wrong keys are slowed down.
- Sharing links can view, never change: no process actions, no settings, no terminal.
The relay: it carries data it cannot read
Keys
- Account key: 32 random bytes made on your first device. It is copied only to devices you pair, inside an encrypted pairing message. The relay never receives it.
- Device keys: every device has its own signing key (Ed25519) that never leaves it, used to log in to the relay. Removing a device stops it logging in.
- Data encryption: AES-256-GCM, with every message bound to its purpose and to the devices at both ends, so the relay cannot replay a message in another context or redirect it to another device.
Pairing a new device
- A pairing code has 16 characters. Four are a lookup number; the other twelve (60 bits) never reach the relay and protect the account key, stretched with 300,000 rounds of PBKDF2.
- A code works once and expires after 10 minutes. Guessing it offline would take far longer than that.
- The recovery code (account and key) is shown once, for you to keep. The relay keeps only a hash that lets a device holding it re-join.
What the relay can and cannot see
| The relay can see | The relay cannot see |
|---|---|
| Account and device numbers, device types (Linux, macOS, browser) | Device names |
| When devices are online, their IP addresses | Readings, processes, networks, devices around you |
| Message sizes and timing, which device talks to which | History summaries (stored, but encrypted) |
| That a terminal session is open, and its duration and volume | Anything typed or shown in a terminal |
Version 4.0 uses the same relay protocol as 3.3, so machines on either version can share one account, and upgrading keeps the pairing.
The relay is deliberately small. Its protocol is documented in full, and automated tests check every part of it, including that the relay's own database holds no readable names, readings or keys.
Terminal sessions
A terminal gives whoever uses it the same power as the person signed in, so it has more locks than anything else:
- Off until you switch it on at that machine. No other device, and not the relay, can switch it on remotely.
- Only the machines you allow. You tick which of your devices may connect.
- Asked each time (on by default): a prompt appears on the machine naming the device that wants in. No answer within a minute means no.
- Proof of who is asking. The request is signed by the requesting device's own key and checked against your allowed list; requests that are stale, replayed or altered are refused without a reply.
- Keys for this session only. The two devices agree a fresh key pair (X25519) for each session; every keystroke and every screen update is encrypted with it and numbered, so nothing can be read, inserted, removed or replayed in between. Other devices on your account can't read it either.
- Never as an administrator. The shell runs as the signed-in user. Machines refuse terminal sessions when running as root or an elevated administrator, and on servers
moxon servicerefuses to run the agent as root. - Time limits and visibility. Sessions end after 15 minutes without typing or 8 hours in total. Open sessions show a banner with an End button, and a notification appears when one starts.
- A log without content. Who connected, when and for how long, and every refusal, are logged on the machine. What was typed is never recorded.
Packet capture 4.0
Packets can contain anything that crosses the network, so capture is kept narrow:
- Every capture asks for the administrator password. The part that runs as administrator is a short script that checks its arguments and runs tcpdump on one interface with a time limit of at most an hour.
- The packets go only to the app of the person who started the capture. Only headers are kept unless you ask for full packets.
- Capture is only available in the machine's own window: never through sharing links, the relay or another machine.
- A capture is held in the app's memory and written to disk only when you press Save .pcap, as a .pcap file in your own Documents folder.
Signed packages
The apt package source is signed. apt refuses packages whose signature does not match the key you added, so a tampered mirror or download cannot slip in a different program. The signing key is kept offline on the developer's own computer, never on the download server.
Key: Moxon Metrics packages, fingerprint 4704 4752 DC5B F50C 34D5 0367 139F A85F D421 7C65. Compare it with gpg --show-keys /usr/share/keyrings/moxon-archive-keyring.gpg. Each download also has a SHA-256 checksum in Download.
The helper
Some readings need an administrator: per-app network use, everyone's disk use, drive health, and what the network says on the wire. A small helper does only that. It accepts no input from anything, changes nothing, and writes its readings to files every user can read. Listening on the network is passive: the helper never sends packets. Network scans only happen when you ask, from your own user account.
Protecting the window itself
- In 4.0 the window is a native app that loads its page from inside itself, with no browser and no local port to connect to. In 3.3 the window talks to its own local server only, with a token made fresh each time it opens.
- When you view another machine inside your window, that machine's page gets a token that works only for that machine, so a page served by another machine can never reach your own machine's settings, processes or terminal.
- Processes belonging to the system, the desktop session or Moxon Metrics itself can't be paused or ended from the app.