How to send confidential files to your lawyer
Attorney-client privilege is strongest when no third party can read the material. The doctrine has exceptions (translators, necessary intermediaries, inadvertent-disclosure protections under Federal Rule of Evidence 502(b), and jurisdiction-specific carve-outs), but the underlying test still matters. If a vendor in the middle of the transfer can decrypt the file, the privilege analysis gets harder. “Our cloud storage provider does not count as a third party” is a defensible argument in some cases. “The vendor could not read the file even with physical access to its servers” is a stronger one, and it is the property this pattern gives you.
The practical problem is familiar. A client needs to send a document to outside counsel: opposing-party disclosures, an intake form, a draft settlement, a tax return. The requirements are simple to state and hard to satisfy together:
- The file reaches its recipient intact.
- No readable copy sits on a third-party server afterward.
- The vendor in the middle cannot decrypt it, by subpoena or by insider.
- There is a reasonable record that the transfer happened.
Most tools handle the first. Some handle the fourth. Few handle the second and third at the same time.
Where standard tools fall short
Email attachments live on the sending server, the recipient’s inbox, every intermediate backup, and whatever archive the firm’s IT has configured. Reaching all of those to delete copies after a matter closes is rarely possible and almost never attempted.
Dropbox, Google Drive, and OneDrive link shares all involve a vendor with the technical ability to read the file. “Encryption at rest” is encryption where the vendor holds the key. A subpoena, a database breach, or a bad actor with admin access all produce plaintext. Retention defaults are measured in years.
Matter-management platforms (Relativity, NetDocs, Clio) solve the audit trail but add friction for recipients without accounts, and still store a readable copy centrally.
None of these are wrong in every context. They are wrong when the file is sensitive enough that a vendor-held readable copy would itself be a problem.
What an end-to-end, ephemeral transfer changes
The file is encrypted in the sender’s browser with a password that never leaves that device. The server stores ciphertext, a log row per action, and nothing else that could be turned into plaintext. The recipient opens the link, types the password, and the browser decrypts the file locally.
Three consequences follow:
- The vendor cannot read the file: the password never reaches it, unless someone who has the password hands it over with an abuse report. A subpoena to the operator yields ciphertext and audit metadata; it does not yield the file.
- The file is deleted from the server after one authenticated download (burn after reading), or when the expiry timer (TTL) you set at upload runs out, whichever comes first. Loading the landing page does not consume the file. A download that fails before the server has sent any encrypted data rolls the counter back; once encrypted bytes have started leaving the server, the file counts as consumed: if the connection drops, only that same download can pick up where it stopped, for a few minutes, and otherwise the recipient needs a fresh upload.
- A transfer record survives. The server logs the upload, the download action, timestamps, hashed and encrypted IPs with their approximate location and network, and user agent. You see it too: the success page and My uploads show when the file was downloaded, and Notify me sends a browser notification when it happens. That is evidence that a file was uploaded and later downloaded from some IP: useful for the sender’s own records, weaker than a signed acknowledgement from the intended recipient, since the link and password together are sufficient to trigger the download event.
| Stored on the server | Not stored on the server |
|---|---|
| The ciphertext, until downloaded or expired | The filename |
| URL token, upload timestamp, byte size, action (upload / download / burn) | The file contents |
| The IP of each party (the sender’s at upload, the recipient’s at download), both HMAC-hashed (audit index) and AES-encrypted (decryptable by the operator for abuse investigation), with the country, city and network it belonged to at that moment | The password |
| User agent and browser language list for each event | The derived encryption key |
| A hash of the 32-byte download token (authenticates the recipient’s download) | Anything that can become plaintext |
Workflow for a document transfer
- Open ttl.space on the device that already has the file.
- Drag the document into the upload area. Turn on Burn after reading for a one-recipient transfer. Every upload also has an expiry timer (TTL, 1 day unless you change it), and it runs with burn on too: a file nobody downloads in time is deleted when the timer runs out.
- Share the link over the normal channel. Email is fine; the link on its own points at ciphertext.
- Share the password over a different channel: SMS, a phone call, a secure messenger. Sending the link and the password in the same email defeats the split.
- The recipient opens the link, enters the password, and downloads. Decryption happens in their browser, not on the server. With burn after reading on, the file is used up the moment the download starts and the server deletes its copy two minutes after the download ends; otherwise the file stays until its timer runs out.
When the matter closes, there is no vendor-held copy to worry about. The operator retains the audit log row for abuse-investigation purposes; the log contains no filename, no file contents, and no password.
If you are the lawyer: let clients upload to you
The other direction is the more common one: you need a client’s documents. With an Orbit plan you can create a file request, a link anyone can use to send you files without an account. The client’s browser encrypts each file before upload and seals its password so that only your browser can open it; the server keeps ciphertext it cannot read. A request stays open for 1, 7 or 30 days, takes up to 100 files, and can email you when something arrives. How file requests work.
Limits
End-to-end encryption covers the pipe between two devices. It does not cover the recipient’s device after decryption. If outside counsel saves the file to their Downloads folder and leaves it there, that is a separate problem, and no sharing protocol addresses it. The same applies if the file is opened on a machine shared with non-privileged staff.
Password strength remains the realistic weak point. A short, memorable password is guessable; an autogenerated 16-character one is not. Use the generated password, not a memorized one, and deliver it through a channel the opposing party cannot read. Do not reuse a password across transfers.
This is not a matter-management system. It does not track case numbers, assign billing codes, or produce production-ready disclosure records. It does one thing: move a file from one device to another without a third party holding a readable copy. For that specific job it is a useful tool; for the rest of the lifecycle you still need whatever case-management system the firm already runs.