Transparency report

Why trust
CYPH3RDROP?

Trust is earned by showing your work. This page explains exactly what we do, what data we handle, how the encryption works, and what the limits of that security are. No marketing. No vague assurances.

What we do

CYPH3RDROP is a zero-knowledge secret sharing service. You paste a sensitive piece of text — a password, an API key, a private note — into our tool. Your browser encrypts it. We store the encrypted result. You get a one-time link. The recipient opens it once, sees the secret, and the data is permanently deleted from our servers.

We do not offer file hosting, messaging, or persistent storage. We do not offer accounts, profiles, or user history. Every secret we hold has an expiry: it is deleted when the link is opened, or after 7 days, whichever comes first.

We are not a general-purpose secure storage platform. We are a one-time transfer tool designed to get a secret from point A to point B without leaving a trace in either direction.

Data we do and don't collect

We have designed the system to collect as little as possible. Here is the full picture.

What we store

Encrypted ciphertextAES-256-GCM output — unreadable without the key, which we never hold.
A random secret IDUsed to locate the blob when the link is opened. Contains no personal information.
A creation timestampUsed to enforce the 7-day expiry. Deleted with the secret.

What we never store

Your IP address or location
Browser fingerprint or device info
Your name, email, or any account data
The decryption key — ever
Cookies, analytics, or tracking scripts
Any log linking a secret to its creator

Our infrastructure runs on Vercel (hosting) and Upstash Redis(encrypted blob storage). Vercel collects standard server access logs as part of their infrastructure — these are governed by Vercel's own privacy policy and are not accessible to us. Upstash stores only the encrypted blobs we send them; they have no access to the plaintext or the decryption keys.

Security architecture

The security of CYPH3RDROP is not based on policies or promises — it is enforced by the technical architecture. Here is how each piece works.

CYPH3RDROP encryption flowShows how a secret travels from the sender's browser through the server to the recipient's browser, with the key staying in the URL fragment only.SENDERBrowser encryptslocally (AES-256)ciphertext onlySERVERStores encryptedblob onlyfetch + deleteRECIPIENTBrowser decryptslocally from #keycyph3rdrop.com/s/secret-id#encryption-key↑ fragment never sent to server

AES-256-GCM encryption. Your secret is encrypted using the Web Crypto API built into every modern browser. The algorithm is AES-256-GCM with a randomly generated 96-bit IV per secret. The encryption key is 256 bits, generated fresh for every secret in your browser. It never leaves your device.

The URL fragment trick. The decryption key is embedded in the URL fragment — the part after #. Browsers have a well-established behaviour: they never include the fragment in HTTP requests. When the recipient opens the link, their browser fetches the ciphertext from the server using only the secret ID — the decryption key stays on the client side throughout. Our server never sees it.

Atomic retrieval and deletion. When the link is opened, the server retrieves the ciphertext and deletes it in a single atomic operation. There is no window in which two requests could both successfully retrieve the same blob.

7-day auto-expiry. Unopened secrets are automatically and permanently deleted after 7 days, regardless of whether they are ever accessed.

Read the code yourself

The complete client-side encryption and decryption code is publicly available on GitHub. No dependencies, no obfuscation — paste it into a browser console and run runSelfTest() to verify the round-trip yourself.

github.com/cyph3rdrop/cyph3rdrop-crypto →

How users stay safe

One view, then gone

The encrypted blob is deleted the instant the link is opened. A second request for the same link returns nothing — there is nothing left on the server to return.

Tamper-evident delivery

If someone intercepts and opens your link before the recipient, the recipient sees a dead link. That is a signal — they know something went wrong and can ask you to resend.

No account, no profile

There is no record linking you to any secret you have created. We cannot tell you how many secrets you have made or when. That information does not exist.

No tracking anywhere

No analytics, no cookies, no advertising pixels, no session tracking. CYPH3RDROP does not know who you are, where you are, or what device you are using.

We can't reveal what we don't have

Because we never hold decryption keys, a legal request, a subpoena, or a data breach cannot expose your plaintext. There is nothing readable to hand over.

Open encryption standard

AES-256-GCM is a published, peer-reviewed standard. Our full client-side encryption code is public on GitHub — read it, run it, verify it yourself.

Risk disclosures

No security tool eliminates all risk. Here is an honest account of what CYPH3RDROP does not protect against.

  • Consider
    Link interception before the recipient opens itIf someone gains access to the link before the intended recipient and opens it, the secret is exposed. The recipient will see a dead link and know something is wrong — but by then the data has already been accessed. Use reasonably trusted channels to share links, and confirm receipt with the recipient.
  • Consider
    Recipient device compromiseCYPH3RDROP decrypts the secret in the recipient's browser. If their device is compromised — malware, keyloggers, screen capture — the plaintext can be captured at the moment of decryption. This is outside our control. CYPH3RDROP protects the transit, not the endpoint.
  • Understand
    Not a substitute for a password managerCYPH3RDROP is for one-time transfers. It is not designed for persistent shared access, credential storage, or team-wide secrets management. If you need multiple people to access the same credentials repeatedly, use a dedicated password manager or secrets vault.
  • Understand
    Vercel infrastructure logsVercel, our hosting provider, collects standard server-side access logs as part of their infrastructure. These may include IP addresses of people who access the site. We do not have access to these logs, and they do not contain the content of any secrets — only metadata about HTTP requests.
  • Low risk
    Browser security modelCryptographic operations run inside your browser's security sandbox. The Web Crypto API is implemented by the browser vendor (Chrome, Firefox, Safari, etc.), not by us. Vulnerabilities in a browser's cryptographic implementation are outside our control, though such vulnerabilities are exceptionally rare and patched rapidly.
  • Low risk
    No confirmation of recipient identityCYPH3RDROP cannot verify that the person who opens the link is who you intended to receive it. The link is a bearer token — whoever has it can open it. You are responsible for sharing it only with the intended recipient and through an appropriate channel.

Questions or concerns?

If you have questions about our security architecture, data handling, or anything on this page — reach out. We read everything.

hello@cyph3rdrop.com