Trust & Security

Your history is encrypted on your device

The full content of every item you copy — text, code, links, images — and its metadata are encrypted at rest in the local database using a key sealed by your operating system's secure storage (macOS Keychain, Windows DPAPI, or Linux libsecret). Short titles and previews stay unencrypted so you can search and see snippets. Nobody can read your history by copying the database file off your machine.

The E2E-sync protocol, in plain English

Cross-device sync is off until you sign in and turn it on. When it's on, here is exactly what happens to a clip before it leaves your device:

• A random 256-bit sync key is generated on your first device and sealed in your OS secure storage. It never leaves the device in the clear.
• Every clip's content, preview, title, and metadata are encrypted with AES-256-GCM (authenticated encryption) — the cloud store sees ciphertext only. File and image bytes offloaded to storage are encrypted the same way.
• The sync key is wrapped by a key derived from a one-time recovery code(~100 bits of entropy) using PBKDF2-SHA256, 600,000 iterations. Email/password users can add a second password-derived wrapper for convenient web access. Only wrapped keys, salts, and KDF parameters live in the cloud.
• The recovery code is shown when it is issued. Pasteable cannot retrieve it, but an already-unlocked trusted device can replace it without changing the sync key or deleting history. Password changes rewrap the same sync key; password resets fall back to the recovery code or a trusted device.
• Only envelope metadata is visible to the server: item type (text/image/file), timestamps, device id, and a content hash used for cross-device dedup. The hash reveals whether two clips are equal, not what they contain.

Desktop keeps the unwrapped key in OS secure storage and mobile uses its secure key store. The web app keeps the key only for the current browser session and decrypts clips locally. A new browser must unlock with its connected account password or recovery code; Google accounts use the recovery-code or trusted-device path.

Sensitive content stays private

Pasteable skips captures from known password managers (1Password, Bitwarden, LastPass, Dashlane, and similar) by default, and you can add your own ignored apps, file types, and formats. With “Blur sensitive content” on, passwords and API keys are visually hidden in the shelf so shoulder-surfers and screenshots do not leak them. Detection is heuristic and runs on-device. When hosted Pro AI is enabled, a bounded classifier can flag subtler secrets the heuristic misses — flagged clips are still captured and encrypted, never deleted, and excluded from team workspaces.

Telemetry, exactly

We collect coarse, enumerated buckets to understand how the product is used — never free text, never clipboard contents.

• Collected: page views, signups, downloads, checkout/billing milestones, onboarding funnel steps (by screen id, not content), and coarse in-app engagement (e.g. “a text clip was copied”, “an AI action ran”) — all length-capped buckets.
• Never collected: clipboard contents, file paths, window titles, AI prompts/results, personal data, or error stack traces (errors are a short code).
• Off switch: Settings → “Help improve Pasteable”. The opt-out is checked in the app before any network call, so “off” means off — no events leave your device, and the server cannot opt you back in.
• Crash reports are a separate, opt-in toggle (off by default). A local log is always written for self-diagnosis; remote reports, when you enable them, contain error text, version, and platform — never clips.

Independent audit scope

We publish the surfaces a security review should cover so an independent auditor (or you) can verify the claims above against the source: the E2EE crypto module (algorithm choices, IV/tag handling, KDF cost), on-device key storage (OS sealing, no clear-text export), the sync engine (encrypt-before-write, decrypt-after-read, file/image blob encryption, storage garbage collection), the Firestore and Storage security rules (owner-only access), the renderer IPC surface (no privileged escape), and the telemetry layer (no content, opt-out honored client-side). The trust boundary is your device: inside it, plaintext and keys; outside it, ciphertext and envelope metadata only. The full specification lives indocs/SECURITY_AND_TRUST.mdin the source tree.

Self-host the sync relay

Because all content is end-to-end encrypted, the sync backend is a “dumb” encrypted store: it holds ciphertext and routes change notifications, and never needs to decrypt anything. That means a self-hosted relay operator cannot read user data even when they run the relay themselves. A self-host relay needs only four things: an encrypted per-user document store with realtime change notifications, an encrypted blob store for files/images, auth scoped to each user's own path, and optional server-side retention enforcement. Today the relay is Firebase-managed (Firestore + Cloud Storage + Functions + Auth), serving purely as the untrusted store. A reference self-host relay with a pluggable storage backend is on the roadmap; because the crypto layer is independent of transport, swapping relays is a transport change, not a security re-architecture. Until then, users who need fully self-hosted infrastructure can keep cloud sync off — local-only history never leaves the device.

What we do not do

• We do not read, scan, or analyze your clipboard contents.
• We do not sell or rent your data to third parties.
• We do not use your data to train models.
• We do not show advertising.
• We do not receive your password — Firebase Auth manages sign-in.
• We do not see your card number — Stripe handles payments.

Your data, your controls

• Delete individual items or your entire history from the app.
• Export your history from Settings → Data.
• Set automatic retention limits by days and item count.
• Disable sync, sign out, or request full account deletion.