Collect Files From Clients Without an Account — and Without the Host Reading Them

A file request is a one-way upload link

You generate a link, send it to a client, and they drop a passport scan or a signed contract into a folder you control. No account. No app. No login. They never see your other files. Dropbox, OneDrive, Tresorit and Beebeeb all ship some version of this. The thing nobody puts on the feature page is who can read what lands in that folder. For most providers, the answer is the provider.

Dropbox encrypts file-request uploads in transit and at rest with AES-256, but Dropbox holds the keys. OneDrive's Request Files works the same way, and it's gated behind a Microsoft 365 work or school account — personal OneDrive, even paid, doesn't include it. So the document your client assumed was private sits on the host's servers in a form the host could open. If you're collecting documents under GDPR, that host is now a processor you have to account for.

Where accountless uploads leave a gap

The appeal of a file request is that the uploader needs nothing. But that convenience usually comes from the host doing the encryption itself, on its own servers, with its own keys. "Anyone can upload" and "the host can read it" travel together, because the easy way to accept a file from a stranger is to receive it in the clear and encrypt it after the fact.

If the host generated the key, the host can use the key. Encryption at rest protects you from a stolen disk. It does nothing against the host itself, a subpoena served on the host, or an attacker who reaches its key store. For an intake folder full of things people sent you in confidence, that is precisely the risk you wanted gone.

How accountless and zero-knowledge coexist

You can keep the no-account upload and still hand the host nothing readable. Do the encryption in the uploader's browser, sealed to a key only you can open. Tresorit built end-to-end encrypted file requests on this idea years ago, and credit where it's due — they shipped it first. Here is the mechanism Beebeeb uses.

Each file request gets its own X25519 keypair. The public half rides inside the link you share. The private half is wrapped under your account's master key and stored on the server, which never sees it in the clear. When a client opens the link and picks a file, their browser does the work:

• It generates a random content key and encrypts the file with AES-256-GCM.
• It mints an ephemeral keypair, runs X25519 key exchange against the request's public key, and feeds the result through HKDF-SHA256 to derive a one-time seal key.
• It seals the content key with that seal key and uploads only ciphertext plus its own ephemeral public key.

What the server ends up holding is a blob it can't open and an ephemeral public key that's useless on its own. To recover the file, you unwrap the request's private key with your master key, redo the exchange, and decrypt. Your master key is derived from your passphrase with Argon2id and never leaves your device. The low-order-point check on the curve lives in shared Rust, so the web app and the CLI produce byte-identical results. The uploader proves none of this. They see a drag-and-drop box.

What you give up

Real end-to-end encryption costs you two conveniences, and it's only fair to name them. The host genuinely cannot scan uploads for malware, and it cannot recover your files if you lose your master key. There is no key escrow, by design — Beebeeb's BIP39 recovery phrase exists exactly because we can't reset what we can't read. And you identify uploaders by the email they type, not a verified login, the same as Dropbox and Tresorit. That field is a label, not an identity check. If you need proof of identity, layer it on top.

Setting one up

File requests are available now in the Beebeeb web app. Native mobile and desktop apps are coming soon.

1. Pick the destination folder for the intake, or create one.
2. Generate a file request on it. Set an expiry, and add a passphrase the uploader must enter if you want one. These are the same controls Beebeeb's encrypted shares use, plus revoke-any-time.
3. Send the link. Your client opens it, types an email, drags files in. Done — no account, nothing installed.
4. The uploads appear in your folder, decryptable only with your master key.

The accountless link is the part your client sees. The crypto sealed to your key is the part they never have to think about, and the part the host can't route around.

How the options compare

If the intake is casual and the documents aren't sensitive, Dropbox or OneDrive file requests are fine, and you may already pay for one. Concede that honestly. The calculus flips the moment "the host can read this" stops being acceptable: a lawyer collecting case files, an accountant pulling tax records, a clinic gathering intake forms. Then you want the upload sealed to a key the host doesn't hold.

Tresorit and Beebeeb both clear that bar. Tresorit’s free Basic plan is small — 3 GB on two devices — so using it for real client intake usually means a paid plan; our honest Beebeeb-vs-Tresorit comparison walks through pricing, open-source posture and where each one fits. Beebeeb is open source on the client side, stores data in Falkenstein, Germany under an EU operator, and applies zero-knowledge on every tier, no exceptions — enough to wire up a real intake workflow before you spend a cent. Paid plans start at €10.99/mo for 1 TB and scale to 99 TB self-serve at +€10.99 per extra terabyte, with a custom quote beyond that.

An independent audit is planned, and we'll publish the findings. Until then the strongest claim we'll make is the one you can check yourself in the open-source client: the bytes that leave a client's browser are already sealed to a key we don't have.