Secure Sharing

How sharing works

When you share a secret from Claspt, the data is encrypted on your device and uploaded as an opaque blob to the Claspt sharing server. The decryption key is placed in the URL fragment (the part after #) — which is never sent to the server.

Your Device                          Claspt Server                     Recipient
    │                                      │                                │
    │  1. Encrypt secret with              │                                │
    │     random sharing key               │                                │
    │                                      │                                │
    │  2. Upload encrypted blob ──────────►│  Stores opaque blob            │
    │                                      │  (cannot decrypt)              │
    │                                      │                                │
    │  3. Generate link:                   │                                │
    │     share.claspt.app/abc#KEY         │                                │
    │     └─── server sees ──┘└─ never ──┘ │                                │
    │                                      │                                │
    │  4. Send link to recipient           │                                │
    │     (email, chat, etc.) ─────────────┼───────────────────────────────►│
    │                                      │                                │
    │                                      │  5. Recipient opens link       │
    │                                      │◄────────────────── requests ───┤
    │                                      │                                │
    │                                      │  6. Returns encrypted blob ───►│
    │                                      │                                │
    │                                      │  7. Browser decrypts locally   │
    │                                      │     using key from URL #       │
    │                                      │     fragment (never sent to    │
    │                                      │     server)                    │
    │                                      │                                │
    │                                      │  8. Plaintext displayed        │
    │                                      │     in browser only            │

The critical insight: browsers do not send the URL fragment (everything after #) to the server. This is defined in RFC 3986 §3.5. The decryption key never leaves the recipient's browser. The server only ever handles encrypted ciphertext.

Creating a shared link

Receiving a shared secret

Recipients do not need a Claspt account or the Claspt app to view shared secrets.

Expiry and burn-after-reading

Time-based expiry

Shared links expire after the time you set (default: 24 hours). After expiry, the encrypted blob is deleted from the sharing server. Even if someone has the link, there is nothing to download. Expiry is enforced server-side — the blob is purged regardless of whether it was accessed.

Burn-after-reading

When enabled, the encrypted blob is deleted from the server immediately after the first successful download. This means:

• The recipient can view the secret exactly once.
• If anyone else opens the link afterward, they see a "This secret has been burned" message.
• The sender receives a notification in Claspt confirming the secret was viewed (with timestamp).
• If the recipient's browser fails to decrypt (wrong password, corrupted download), the blob is still consumed. A new link must be created.

View count limit

Alternatively, set a maximum view count (e.g., 3 views). The server tracks download count and deletes the blob once the limit is reached. This is useful when sharing with a small team — everyone can view it, but the link dies after N accesses.

Zero-knowledge architecture

The Claspt sharing server is intentionally designed to know as little as possible about the secrets passing through it.

Even if the Claspt sharing server is compromised — by an attacker, a government subpoena, or a rogue employee — the attacker gets encrypted blobs with no way to decrypt them. The decryption keys exist only in the shared URLs, which the server never receives.

Limitations and best practices

Limitations

• Link security is URL security. Anyone with the full URL (including the fragment) can decrypt the secret. Treat shared links with the same care as the secret itself.
• No recipient verification. Claspt does not verify who opens the link. If the link is intercepted or forwarded, the interceptor can view the secret. Use password protection and separate delivery channels to mitigate this.
• Browser history. The full URL (including fragment) is stored in the recipient's browser history. For sensitive secrets, recipients should use private/incognito browsing or clear their history afterward.
• Clipboard risk. When the recipient copies decrypted data, it enters their system clipboard, which may be accessible to other applications. Clear the clipboard after use.
• Max blob size: 1 MB per shared secret. This covers virtually all credential and key sharing use cases.

Best practices

• Use burn-after-reading for one-time credential handoffs (onboarding a new team member, sharing an API key with a contractor).
• Set short expiries. 1 hour is usually sufficient for sharing credentials you know the recipient is expecting. Shorter windows reduce exposure.
• Add a password for high-value secrets. Send the password via a different channel than the link.
• Use Claspt Pro's notification to verify the intended recipient accessed the secret. If the blob was accessed before you expected, consider the secret compromised and rotate it.
• Don't share via public channels. Posting a Claspt sharing link in a public Slack channel or email thread gives access to anyone in that channel.