What your clipboard manager actually sees: a threat model

People often treat clipboard managers as utilities — something you install and forget. In practice, a clipboard manager has more privileged access to your personal data than most apps on your phone or laptop: links you’re about to send, OTPs you just received, snippets of whatever you’re writing, command-line arguments you don’t want in shell history, private URLs, partial passwords.

This post walks through the realistic threat model for clipboard managers on both Android and macOS — what the operating system lets any app see, what a sync tool specifically adds, what attackers to actually worry about, and what ClipHop does differently.

It’s not a fear piece. It’s a factual map of the trust surface.

What the OS lets apps read#

macOS#

On macOS, the clipboard is essentially public to any app with foreground access. NSPasteboard / UIPasteboard APIs are available to any signed app — no special permission prompt. Apps can poll the clipboard continuously if they want (though aggressive polling is throttled by the system).

macOS 14 added user-visible toasts when an app reads the clipboard in a way that wasn’t user-initiated, and some apps respect NSPasteboardTypeTransient and NSPasteboardTypeConcealed flags (used by password managers to signal “don’t log this”). Those flags are advisory — a malicious app can ignore them.

Android#

Pre-Android 10, any app could read the clipboard at any time, including in the background. Post-Android 10, background clipboard reads are blocked — only the foreground app can read. Post-Android 13, the system shows a “Content pasted” toast when an app reads the clipboard. Post-Android 13, there’s also a paste-preview masking option (which ClipHop respects) to hide clipboard content from system keyboard paste suggestions.

The bottom line#

The clipboard is less protected than, say, contacts or location. Any app you’ve trusted enough to install has a plausible way to observe what you copy. A clipboard manager voluntarily occupies that observer role so you can search / pin / sync your clipboard history — you’re trading observation access for utility.

That’s fine. The question is what the manager does with that access.

What a sync tool adds#

A clipboard sync tool specifically does two things the OS clipboard doesn’t:

1. Reads from the source device (like any clipboard manager).
2. Writes to the destination device (a capability the OS clipboard can’t offer across device boundaries).

Both sides are in the trust surface. A compromised sync tool can:

• Log every clip before sending.
• Forward clips to a third party.
• Inject arbitrary content into the destination clipboard (e.g., swap a bitcoin address mid-paste).
• Read local history long after the clip was “forgotten.”

None of those are hypothetical attacks — clipboard-swap malware is a documented real-world category, especially for cryptocurrency addresses.

The attacker classes worth modeling#

For a clipboard sync tool, there are three plausible attacker classes:

1. The sync vendor itself#

This is the attacker many people don’t consciously model but should. If the sync tool routes your clipboard through the vendor’s servers, the vendor has custody of your clipboard stream. That custody is subject to:

• Compromise: credentials breach, server intrusion, backups leaking.
• Subpoena: legal process forcing disclosure.
• Policy change: terms-of-service updates, new parent company after acquisition.
• Employee access: internal abuse by a rogue engineer.

Even “end-to-end encrypted” cloud services usually hold some metadata — who connected when, which devices are paired, session times. For a clipboard stream that routinely contains credentials, any custody position is substantial.

ClipHop’s answer: there is no server. There is no vendor custody. Clipboard text and key material exist only on the two paired devices. We don’t have the option to leak data we never receive.

2. A malicious app on one of your devices#

If you install a malicious app on either device in the pair, the threat model degrades fast:

• It can read the source clipboard directly (on-device).
• It can potentially read the sync tool’s local storage if the OS sandbox is breached.
• On Android, it can try to listen for the sync tool’s foreground service notification to infer activity timing (a side channel).

What sync tools can and can’t do about this:

• Can: store keys in hardware-backed secure storage (Keychain on Mac, Keystore on Android). Doesn’t stop clipboard-level reads, but prevents key exfiltration.
• Can: use the system’s designated “transient” / “concealed” flags so other apps that respect them skip the paste.
• Can’t: prevent another legitimate app from reading the clipboard. That’s the OS’s design.
• Can: bias the product toward manual send, so the clipboard leaves the device only when the user explicitly asks for it (see below).

3. A network observer between devices#

If the sync tool transmits over a network, an observer on that network can attempt:

• Passive eavesdropping (if encryption is weak).
• MITM attacks (if identity authentication is weak).
• Traffic analysis (timing, size, even on encrypted channels).

ClipHop’s answer: transport is Bluetooth LE directly between two paired devices, not a network hop. The attacker has to be within Bluetooth radio range (~10–15 m) to observe traffic at all. Even then: AES-256-GCM with per-reconnect X25519 ECDH session keys, authenticated by Ed25519 long-term identity keys, with user-verifiable identity fingerprints. A passive attacker sees ciphertext. An active attacker has to break the ECDH or impersonate a key — both detected by fingerprint mismatch.

See How ClipHop encrypts your clipboard for the crypto detail.

The content-filtering claim: why it’s mostly a lie#

A common claim on competing clipboard tools is that they “automatically filter out password-manager pastes” so your passwords never sync. It sounds good. It’s also hard to do reliably.

What “password filtering” typically means in practice:

• Check if the macOS NSPasteboardTypeTransient / NSPasteboardTypeConcealed flags are set. Password managers that set these will be filtered. Ones that don’t, won’t.
• On Android, check for the flag on the ClipData that newer password managers set. Older ones don’t.
• Pattern-match for “looks like a password” (high entropy, specific length). False-positive-prone — filters legit tokens, API keys, URLs. False-negative-prone — lets through long diceware passwords.

The result: content-filtering stops some password-manager paste leaks, but you cannot rely on it to catch all of them. OTPs in particular are often unflagged and unfiltered.

ClipHop’s answer: we ship manual send by default. Every clipboard item sits in your history until you tap the ✈ send icon. Your clipboard doesn’t leave the device unless you pick the item. There’s an opt-in Auto-send beta that sends everything automatically — and the app itself warns that auto-send is unfiltered (including passwords and OTPs). We don’t claim filtering we can’t deliver; instead we design the default flow so you’re the filter.

What you can actually check#

Before installing any clipboard sync tool — not just ours — ask:

1. Where does the clipboard go? Server, peer-to-peer, local-only?
2. Who holds the keys? Vendor, device, neither?
3. Can you verify the pairing? Fingerprint, certificate, or just “it worked”?
4. What happens on account compromise? Is there even an account?
5. What’s the send model? Auto-send everything, or opt-in per clip?
6. What’s on disk? Clipboard history, session logs, forwarding queues?
7. What telemetry does it send? Analytics, crash reports, feature flags?

For ClipHop specifically: peer-to-peer only, keys in hardware-backed storage on each device, fingerprint-verifiable, no accounts, manual send by default, history + identity-only on disk, zero telemetry.

Further reading#

• How ClipHop encrypts your clipboard — the cryptographic design in detail.
• Why we chose Bluetooth LE — the transport rationale.
• Privacy policy — what we collect (nothing), what stays on your devices, what permissions we ask for.

The threat model isn’t complicated once you actually look at it. The hard part is matching a product’s design to the threats you care about. For clipboards specifically — a channel that carries credentials more often than any other sync stream — the bar should be higher than “it just works.”