Most "secure share links" are only secure from the public
You right-click a file, generate a link, tick a box for a password and an expiry, and send it. It feels safe. The URL is long and random, it dies in a week, and a stranger who guesses it gets nothing. But there's one party the link isn't secure from: the company hosting it. On Dropbox, Google Drive, and iCloud, the provider holds the keys to the file the link points to. The link decides who else can reach it. It does nothing to stop the provider from reading it, handing it to a government under a warrant, or losing it in a breach.
This is about the other kind of share link: the file is encrypted with a key the server never holds, so "can the provider read this?" answers no — not "no, because of our policy." Here's the mechanism, and how to send one in about thirty seconds.
Where the encryption key actually lives
When you create a share link in Beebeeb, your browser does the work. It generates a per-share key, wraps the file's content key under it, and builds a URL like this:
https://app.beebeeb.io/s/Xb7q…/#key=Kk3p…
The load-bearing character is the #. Everything after it is a URL fragment, and fragments are never sent to the server — the browser keeps them client-side by design. The token before the # is all the server sees; it uses that to look up an encrypted blob. The key after the # decrypts that blob, and it only ever exists in the browsers of the people you send the link to. We do store the share key wrapped under a separate server-side wrapping key, purely so revocation can destroy it — but the fragment that actually opens the file never touches our infrastructure.
That's the difference between "secure from the public" and "secure from us." The decryptor rides in the one part of the URL we cannot see. The cipher is AES-256-GCM; the key wrapping and zeroizing happen in our shared open-source core crypto library — the same code the web app and CLI compile against. You don't have to trust the marketing. Read the code.
Adding a password the server never sees
The fragment already locks out anyone without the URL. A password adds a second factor: now you need the link and a secret. That matters because links leak — a forwarded email, a screen-shared window, a compromised inbox. A leaked link alone becomes useless.
In the share dialog, enable Require a password and type one or generate a random one. The passphrase is mixed into key derivation before anything uploads, so the server stores a payload it can't decrypt without it. When someone opens the link, the server returns requires_passphrase: true and an encrypted payload; the unlock happens in their browser. We never receive the password, can't brute-force it, and can't reset it. Send it over a different channel than the link — a separate message, a call, in person. If both land in the same inbox, you've defeated the point.
Proton Drive does this too, and does it well: the password decrypts the share, their server never sees it. This is one of the areas where the honest answer is that we match a strong competitor rather than beat them — if you're weighing the two, our honest Beebeeb-vs-Proton-Drive comparison says so plainly. The real gaps are elsewhere: price per terabyte, where the data physically sits, and that zero-knowledge is the default on every Beebeeb tier, including the free one.
Expiry and a maximum number of opens
A link that lives forever is a liability you'll forget about. Two controls fix that, both in the same dialog. Expiry takes a window from one hour up to thirty days; after it passes, the server stops returning the payload, and there's nothing to decrypt even if someone saved the URL. Max opens caps successful accesses — set it to 1 for a true one-time link, where the recipient downloads once and the next click gets nothing. Useful for a contract meant to be read exactly once, or a credential you're rotating.
These aren't honor-system limits enforced in the UI. They're checked on the server for every request, so editing the URL or replaying it later doesn't get around them.
Revoking a link, cryptographically
Sent the wrong file? Wrong person? Open My shares and revoke it. On most platforms, "revoke" flips a permission flag — the link 404s, but the underlying file and its keys are untouched, and you're trusting the provider's access control to hold.
Ours is stronger. Revoke NULLs the two stored values that make decryption possible: the wrapped share key and the wrapped file key. Once they're gone, the encrypted blob on disk is noise. Even someone who copied the full link — fragment and all — before you revoked it is left with ciphertext and no path back to plaintext. There's no "we'll stop serving it" to take on faith. The math stops working.
Send one in thirty seconds
The whole flow: right-click a file and choose Share link. Set an expiry — for anything sensitive, a day or two is plenty. Turn on a password, generate it, copy it. Optionally cap max opens at 1. Copy the link, and send the link and the password over separate channels. The link copies with the #key= fragment attached, and the clipboard auto-clears after sixty seconds so the key doesn't linger.
One honest limit: a share link is only as private as the people you send it to. We can guarantee that we can't read the file. We can't stop a recipient from saving a copy or forwarding the password. Encryption protects the file in transit and at rest — not from someone you deliberately handed the keys to. That's true of every E2E system, and any provider claiming otherwise is selling you something.
All of it — expiring links, passwords, max-opens, and cryptographic revocation — works the same on the free plan or a paid one. Beebeeb's free 5 GB tier is fully zero-knowledge, so you can send a few of these and watch the mechanism yourself before paying anyone. Your files sit on dedicated servers in Falkenstein, Germany; the keys stay in your browser. We built it that way so "can you read my files?" has a real answer, not a policy.