What End-to-End Encryption Means in a Clipboard App

"End-to-end encrypted" gets stretched a lot, especially in marketing copy for clipboard and file-sharing apps. The phrase has a precise technical meaning, and most products that claim it don't actually qualify. Here's what the term really requires, where common implementations fall short, and how Clipcroft's optional clipboard password fits the definition.

What "end-to-end encryption" actually requires

The shortest correct definition: only the endpoints can read the content. Not the server. Not the network. Not even the company that runs the service. Three concrete things have to be true:

1. The encryption key never leaves the endpoints. If the server ever sees, generates, or stores the key, the system is not end-to-end encrypted — it is merely "encrypted in transit" or "encrypted at rest", which are different and weaker properties.
2. The plaintext never reaches the server. The data has to be encrypted on the sending device before it's transmitted, and decrypted on the receiving device after it arrives. Anything in between, including the server, sees only ciphertext.
3. The server can't trick the endpoints into giving up the key. This is the subtle one. If the server can swap a key out, hand a malicious key to the receiver, or otherwise sit between the endpoints, the system has a man-in-the-middle weakness even if everything else is correct.

Why most "encrypted" clipboard apps don't qualify

TLS is not end-to-end encryption

The most common bait-and-switch is conflating TLS (the encrypted-in-transit guarantee that protects data between your browser and a server) with end-to-end encryption. Every reputable clipboard app uses TLS — that's just HTTPS. But TLS terminates at the server. Once your data arrives there, it's plaintext. The server (and anyone with access to it) can read everything. TLS protects against eavesdroppers on the network; it does not protect against the service provider.

Server-held keys are not end-to-end encryption

Some products generate an encryption key for you and store it on their servers. The marketing copy will often say "your files are encrypted on our servers" — and that's true, but the key is right next to the ciphertext. Anyone with admin access to the database can decrypt everything. This is encryption-at-rest, which is a useful property (it protects against database leaks), but it's not end-to-end and it does not protect you from the company itself.

Server-generated keys delivered "securely" are not end-to-end encryption

A more sophisticated approach is for the server to generate a key per session and "give" it to both endpoints over an encrypted channel. The intent is good, but the server has held the key, even briefly. Trustworthy E2E systems require that the server never sees the key in any form.

How Clipcroft's optional clipboard password works

Clipcroft's default mode is browser-to-browser via WebRTC, which is a different privacy story (the file never reaches our servers at all). For clipboards where you want the stronger guarantee — that even if WebRTC's signaling layer were compromised, your data would still be opaque to us — you can set a clipboard-level password when creating the clipboard.

Here's what happens, step by step:

1. You set a password in your browser. The password itself never leaves your device. It's not sent to our servers, not logged, not stored anywhere off your machine.
2. Your browser derives an encryption key from the password. We use PBKDF2 with a per-clipboard random salt, then AES-GCM as the encryption primitive. The derivation happens in JavaScript using the browser's native SubtleCrypto API.
3. A second device opens the same clipboard. When that device receives an item, it sees only ciphertext until the user types the same password. Without the password, the data is unreadable.
4. Encrypted items travel through the network. Whether they go through the WebRTC peer-to-peer path or are relayed via the signaling server, all our infrastructure ever sees is ciphertext.
5. The receiving browser decrypts in memory. The decrypted content lives only in the browser tab. It's never written to a server.

What we — Clipcroft, the company — can see in that flow:

• That a clipboard exists and is marked as protected (a single bit on the signaling envelope).
• The size of each ciphertext blob (because metadata isn't encrypted).
• The timing of each transfer.

What we cannot see:

• The password.
• The plaintext content of any text message.
• The plaintext content of any file.
• The filenames of files (these are also encrypted).

What this protects against — and what it doesn't

Threat-model honesty is part of taking encryption seriously. Here's what an optional clipboard password protects against:

• A network adversary monitoring traffic between your browser and our servers.
• A compromise of our signaling server or its logs.
• A subpoena or legal request that would force us to hand over data we hold.

And here's what it does not protect against:

• A compromised endpoint. If malware is running on either device, it can read the plaintext after decryption — no encryption protocol can fix that.
• A weak password. If your password is guessable, an attacker who obtains the ciphertext can attempt offline brute-force decryption. PBKDF2 with a high iteration count makes this expensive but not impossible. For sensitive content, use a long, unique password.
• Side-channel leakage from metadata. File sizes, timing, and the fact that a transfer happened are visible to our servers. For most threat models this is fine; for serious counter-surveillance work, it isn't.
• Sharing the password insecurely. The strongest encryption is undone by sending the password through an insecure channel. If you tell someone the password over an unencrypted email, anyone reading the email can also unlock the clipboard.

Why we made it optional

The default Clipcroft flow already has a strong privacy property: files never touch our servers thanks to WebRTC peer-to-peer. For most users — sharing photos between their own devices, moving a document from a work laptop to a home PC — that's already plenty.

End-to-end encryption adds a second layer. It's the right choice when:

• You're sharing genuinely sensitive content (financial documents, medical records, credentials).
• You don't fully trust the network path between the devices.
• You want a "Clipcroft-can-never-read-this" guarantee, even at the cost of remembering and securely sharing a password.

For everything else, the default is good enough. We made encryption opt-in instead of default because:

• It requires the receiver to enter the password before they can see anything — a small friction that's worth it for the cases where E2E matters and unnecessary for the cases where it doesn't.
• If the password is forgotten, there's no recovery. Cryptographic systems that allow recovery aren't end-to-end encrypted.

How to use it

1. On the device that creates the clipboard, click Create new clipboard and set a password in the optional field. The password must be at least 6 characters; longer is better.
2. Share the clipboard link (which contains a one-time verifier token) with the other device. Send the password through a different channel — in person, over an encrypted messenger, or any path you trust.
3. On the second device, open the link and enter the password. The browser derives the key locally and decrypts the clipboard items.
4. Both devices can now send and receive encrypted text and files. Anything new that lands on the clipboard is encrypted automatically.

The short version

End-to-end encryption isn't a feature flag — it's a property of who holds the key. If the server can ever see the key, the system isn't E2E. Clipcroft's optional clipboard password is a real E2E layer: the password stays on your device, the key is derived locally, and our servers see only ciphertext, file sizes, and timing. For everyday clipboard sync, the default WebRTC peer-to-peer flow already keeps your files off our servers. For sensitive content, the optional password adds a guarantee even an admin with full database access can't break.