Privacy & security
A clipboard manager sees passwords, private messages and keys. This page explains, in plain words, how ClipTrail handles that, including what isn't finished yet.
The short version
- Local-first. Your history lives in a folder on your device. Every app works offline and alone.
- No telemetry. No analytics, crash reports or accounts. The apps never contact a ClipTrail server; there isn't one. The only optional exception is the desktop update check, which is off until you turn it on (see below).
- End-to-end encrypted sync. Only devices you paired can read your clips. Sync stays on your local network.
- Secrets handled carefully. Password managers are excluded; codes and keys are masked, unsearchable, never synced and short-lived.
- Open source. Every line is on GitHub under the MIT license.
What's protected where
| Where your clips are | How they're protected today |
|---|---|
| On your device | In your user's data folder. The SQLite database is encrypted with ChaCha20-Poly1305 and image files with XChaCha20-Poly1305; the key lives in your OS keychain (Windows Credential Manager, macOS Keychain) or in the app's private storage on Android and Linux. Anyone who can sign in as you can still open the app and read your history. |
| On the network | Each clip and image is sealed with XChaCha20-Poly1305 (256-bit key, random 192-bit nonce) on the device that copied it. Eavesdroppers see event and device ids, timestamps and sizes, not content. |
| On the hub | The hub is one of your computers. It holds the key, so it decrypts clips into its own history just like your other devices. It also keeps the sealed event log so devices can catch up. |
| In logs | Never. Logs and error messages contain ids, kinds and sizes only; this is a hard rule in the code. |
Threat model in plain words
What ClipTrail protects against
- Someone on the same Wi-Fi reading or altering your clips in transit. Everything is encrypted and authenticated; requests are signed with HMAC-SHA256 and timestamped, and the device token itself never travels.
- Someone on the network pairing a device without you. Pairing needs the one-time secret in the QR on your screen, which expires after 10 minutes and works once. Attempts are rate-limited, and both devices show a 4-digit check code to compare.
- A lost or replaced device. Revoke it on the hub and its token stops working immediately.
- Secrets lingering in history. Detected secrets are masked, kept out of search and sync, and deleted after 1 hour by default.
- Accidental capture from password managers, via the exclusion list and Windows' "don't record" clipboard flags.
What it doesn't protect against (yet)
- Malware or another person using your unlocked user account. They can read the data folder, as they could your browser history. Database encryption at rest will raise the bar; nothing protects fully against software running as you.
- A device you paired and then lost before revoking still has the clips it already received.
- Metadata. Someone on your network can tell that sync is happening, when, and roughly how much.
- Secrets that don't look like secrets. Detection works by shape (codes, known key formats, card numbers). A plain password copied from a text file looks like text. Use a password manager, or pause capture first.
Password managers and sensitive clips
Three layers keep secrets out of your history:
- Excluded apps. Copies made in 1Password, Bitwarden, KeePass, KeePassXC, Dashlane, LastPass, Enpass, NordPass, Proton Pass, Keeper, RoboForm, Password Safe, Authy and the GNOME/KDE keyrings are never stored. Add any other app in Settings → Privacy.
- Clipboard flags. On Windows, apps can mark a copy as "don't record in history". ClipTrail honours those flags, which many password managers set. Android's "sensitive" flag is honoured by the Android app.
- Detection. One-time codes, API keys, JWTs, private keys and card numbers are recognised by shape, masked, never indexed for search, never synced, and deleted after the lifetime you choose (1 hour by default).
Need to copy something private? Pause capture from the tray or the sidebar for 15 minutes, an hour, or until you resume.
How pairing works
- The hub creates a one-time offer: a fresh X25519 key pair and a random 16-byte secret, valid for 10 minutes. The QR carries the hub's addresses, its public key and the secret.
- The new device makes its own key pair and sends its public key with a proof (an HMAC keyed by the secret) to the hub.
- The hub checks the proof, burns the offer, derives a shared key with X25519 + HKDF-SHA256, and sends back the sync key and a fresh device token, sealed under that shared key.
- Both sides derive the same 4-digit check code from the shared key and show it to you.
Because the QR is shown on your screen, someone on the network can't swap in their own key, forge a proof, or open the reply.
Where keys are kept
- Windows: Windows Credential Manager.
- macOS: the Keychain.
- Linux and Android: a file in the app's data folder readable only by your user (or the app).
No telemetry, no phone-home
ClipTrail makes no network connections except the sync connections between your own paired devices, and the optional update check below. No analytics, no crash reporting, no account. The project's rules forbid adding them.
Update checks (optional)
The desktop app can check for a new version, but only after you opt in: the dashboard asks once, Check for updates automatically in Settings stays off until you switch it on, and Check for updates only runs when you click it. A check downloads one small file (latest.json) from this project's GitHub Releases, so GitHub can see your IP address like for any download. Nothing about you, your device or your clips is sent. If a newer version exists, ClipTrail shows a banner and waits: it never installs silently, and it verifies the update's signature against a public key built into the app before running it. The Android app has no update check.
Found a problem?
Please report security issues privately. See the security policy.