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 under any access path. 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 confirmed authenticated download (burn-after-read), or on a TTL you set at upload. Loading the landing page does not consume the file; a failed download rolls the counter back.
- A transfer record survives. The server logs the upload, the download action, timestamps, hashed and encrypted IPs, user agent, and source port. 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 sender’s IP, both HMAC-hashed (audit index) and AES-encrypted (decryptable by the operator for abuse investigation) | The password |
| User agent and TCP source port 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-read for a one-recipient transfer, or set a 24-hour TTL if the recipient is expected to read it later that day.
- 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. The server then deletes its copy.
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.
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 four-character password is guessable; an autogenerated 24-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.