Send files to a client without a readable copy in the cloud
Handing a client a contract, a design, or a confidential report over a generic transfer tool leaves a plaintext copy on someone else’s servers. For work under an NDA, that’s a gap you can’t always explain away.
ShieldFive Send encrypts each file in your browser before upload, so the deliverable exists only as ciphertext until your client opens the link and decrypts it on their side.
An answer for the NDA clause
“Confidential information will not be disclosed to third parties” sits awkwardly with a transfer service that can open the deliverable. Encrypting on your device, with the key only ever in the link fragment, means the service in the middle is not a party that can read it.
Open-source crypto behind the deliverable
Each transfer is sealed with a random key under XChaCha20-Poly1305 from the @shieldfive/crypto core. If a client’s security team asks how the handover was protected, there is a library to point at.
Retire the link when the job ends
Set an expiry, and the link also stops at its download limit; you can revoke it earlier. Expired ciphertext is queued for deletion, so an old deliverable link is not still live in a year-old email thread.
EU-hosted, nothing readable at rest
Encrypted blobs are stored in the EU with no tracking on the send or download pages — so the copy of your work sitting on our infrastructure is ciphertext, and we never hold the key.
Send a file in seconds
Drop it, share the link, and it’s encrypted before it leaves your device — no account required.
Send files encryptedQuestions
- Can I control how long the link works?
- Yes. You choose an expiry, and the link also stops after its download limit. When it expires or you revoke it, the ciphertext is queued for deletion.
- Does the client need to install anything?
- No. Any modern browser opens the link and decrypts the files locally using the key in the link fragment.