"Sensitive information" covers a lot: a passport scan for a landlord, bank details for an invoice, a tax document for an accountant, a password for a family member, a medical letter, a signed contract. The channels most people use for these, email and chat, were built to keep things, not to forget them.
This guide is a routine you can apply to any of them, in five steps: check who's asking, send less, pick the channel, make it expire, and confirm.
1. Check who's asking
Before you think about encryption, make sure the request is real. Requests for personal details, payment changes and login codes are exactly what phishing imitates. The FTC's advice on recognising phishing is to contact the company using a phone number or website you know is real, not the contact details in the message.
Be especially careful with:
- requests to change the bank details for a payment you were already going to make;
- urgency ("today, or the account will be closed");
- anyone asking you to read out a one-time login code. A code sent to you is there to prove it's you; nobody who contacts you needs it.
2. Send less
Every detail you don't send is one you never have to worry about.
- Send the last four digits of a number when that's enough to identify the account.
- Crop or redact a document to the part that's needed. For an ID, cover the fields you weren't asked for, if the recipient accepts that.
- Add a visible note to scans, such as "For [company] rental application only," which makes a leaked copy less useful for anything else.
- Check photos before sending them: phone cameras can record location data in the file.
3. Pick the channel by what you're sending
| What you're sending | A good option | Avoid |
|---|---|---|
| A password or PIN | A one-time note that burns after reading | SMS, email, group chats |
An API key or .env file | EnvShare, with one read | Chat, tickets, wikis |
| ID scans, contracts, tax documents (up to 25 MB) | An encrypted file drop, or the recipient's own secure portal | Plain email attachments |
| Bank details for a payment | The payee's portal or invoicing system, then confirm by phone | Replying to an email that asked you to change them |
| Something you need from someone else | A secret request | Asking them to email it |
| A login several people use for months | A shared vault in a password manager | A fresh link every week |
If the organisation you're dealing with has its own secure upload portal, that's usually the right choice: it was set up for that data and for its retention rules.
4. Send it so it expires
For anything that only needs to be read once, send a link that deletes itself instead of the information itself.
For text such as passwords, account numbers or short notes:
- Open Secure Notes and paste the text.
- Leave burn after reading on, so the note is deleted from the database the first time it's opened.
- Choose the shortest expiry that works: 1 hour, 1 day, 7 days, or a custom date up to 30 days away.
- For anything high-stakes, add a password and send it another way, such as a phone call.
- Copy the link and send it through your usual channel.
For documents, use a file drop. Files up to 25 MB are encrypted in your browser, file names included, and the drop is deleted after the number of downloads you choose (1 to 100) or at expiry.
Tell the recipient what to expect, especially if they don't use tools like this often. A one-line message such as "This link opens once. Save what's inside before you close it" prevents the most common problem: someone opens the link on a phone, closes the tab, and has to ask you to send it again.
What the server sees, stated plainly: the encrypted data and its size, the timing of requests, and network details such as IP addresses. It doesn't see the content, the file names or the key, which travels in the part of the link after the # that browsers don't send to servers (MDN). The security page lists exactly what's stored.
5. Confirm, then clean up
- Ask the recipient to confirm they received it. My links shows when your link was opened, in the browser you created it from.
- If the link was opened before they say they opened it, assume someone else saw it and act accordingly: change the password, or warn your bank.
- Delete the copies you made along the way, such as a scan sitting in your Downloads folder.
Three common situations
An ID scan for a landlord or an employer. Ask whether they have an upload portal first. If they don't, send the scan through a file drop with one download and a short expiry, and mark the image with what it's for. Only send it to contact details you've confirmed, not to an address from an advert or an unexpected message.
Bank details for an invoice. Put them on the invoice in your usual invoicing tool, or send them in a one-time note. If you're the one paying, never act on an emailed change of bank details without first phoning the payee on a number you already had.
A password for a family member. Send a one-time note, and give the extra password out loud the next time you talk. If your family already shares a password manager vault or a family plan, use that instead, so the password updates for everyone when it changes.
When email is the only option
Sometimes a form or an organisation leaves no choice. In that case:
- Gmail and other major providers use TLS to protect mail between servers when both sides support it, and Gmail shows a red open padlock on messages that weren't encrypted (Gmail Help). That protects the trip, not the readable copies stored in both mailboxes.
- Features like Gmail's confidential mode limit forwarding and downloading, but Google notes that recipients can still take screenshots or photos, and malicious programs may still copy the message (Gmail Help).
- Encrypt the content before it goes into the email. For text, Encrypt text turns it into a password-protected block you can paste into the message. Send the password through another channel.
Receiving sensitive information
If you're the one who needs a document or a password, make it easy for the other person to send it safely. A secret request gives them a link where whatever they paste is encrypted in their browser to a key only your inbox link holds. One answer is accepted, and collecting it deletes it from the server, so copy it somewhere safe when you open it.
What encryption can't do
- The recipient can keep a copy. Once they've read it, it's theirs. Share only with people you'd trust with it anyway.
- A compromised device defeats any tool. If your computer or theirs is infected, encryption in the browser won't help.
- Whoever opens the link first can read it. That's why burn after reading, a short expiry and a separate password matter.
When not to use ProtectedShare
- When an organisation requires its own channel. Many banks, employers, healthcare providers and government services do, and their portals come with the retention and access rules the data needs.
- When records have to be kept. Workplace retention rules or legal holds may require messages to be archived, which a self-deleting link deliberately prevents.
- When several people need ongoing access. Use a shared vault or a document system with proper access controls.
Sources
- FTC, How To Recognize and Avoid Phishing Scams
- Gmail Help, Learn how Gmail encrypts your emails
- Gmail Help, Send & open confidential emails
- MDN, URI fragment