Skip to content
The Security Editor

Sharing securely

Expiring links, access logs, and sending sensitive files to people who aren't technical

Most people you need to share a sensitive document with are not going to install a new app to receive it. Here's how to use the tools you already have — with the expiry, access logging, and revocation features turned on.

By Alex Trustwell 6 min read beginner
On this page
  1. Why default sharing is risky
  2. What to turn on
  3. 1. Require a specific account
  4. 2. Set an expiry
  5. 3. Set a password on the link itself
  6. 4. Restrict to view-only
  7. 5. Turn on access logs
  8. The recipient problem: they won’t install anything
  9. Option A: password-protected PDF, out-of-band password
  10. Option B: a standard cloud share with expiry and a password
  11. Option C: a secure client portal
  12. Option D: ephemeral sharing services
  13. Option E: E2EE sharing via a service that supports link
  14. A workflow to standardize on
  15. An annual audit

Many articles about secure sharing assume both sides of the conversation are willing to install new software. In reality, most of the time you need to send a sensitive document to your accountant, your lawyer, your doctor’s office, a contractor, or a relative — and they are going to open it with whatever they already have. The practical security question is: what’s the best you can do within that constraint?

The answer is usually: use the cloud storage you already have, but turn on the specific features that make sharing safer. Most people never do.

Why default sharing is risky

When you create a standard “anyone with the link” share in Google Drive, Dropbox, OneDrive, or iCloud, you are creating a capability — a URL that grants access to anyone who possesses it. The URL has several ways of getting into the wrong hands:

  • The recipient forwards the email containing it.
  • The email is archived and searched years later.
  • A browser syncs the URL to another device.
  • The recipient’s email is breached.
  • A support conversation references it.
  • Someone stumbles on the URL via a log file, a bookmark backup, or an autocomplete suggestion.

The link does not expire. It does not know who is using it. It does not record who saw it. That is the default.

What to turn on

Nearly every cloud provider supports at least some of these settings, and the combination of them is what turns “a URL” into “a controlled share”:

1. Require a specific account

Instead of “anyone with the link”, share with a specific email address (or set of addresses). The recipient has to sign in with that email to access the file. A forwarded URL is useless without the matching sign-in.

When to skip it: when the recipient doesn’t have an account on the provider and won’t create one.

2. Set an expiry

The link works for a bounded window: a day, a week, a month. After that, it’s inert.

  • Google Drive: set an access expiry per user in the Share dialog’s advanced options.
  • OneDrive: “Set expiration date” when creating a link.
  • Dropbox: “Link expiration” on paid tiers.
  • iCloud Drive: expiry per shared file.

How to pick: slightly longer than you realistically think the recipient needs. A week is a safe default for a reviewable document; a month for a reference file; a year is too long for almost anything.

In addition to the share URL, the link requires a password you deliver separately. This is the online equivalent of the password-protected PDF pattern: the URL and the password travel through different channels.

  • Dropbox, OneDrive, Google Drive (Workspace), and most providers support password-protected links on paid plans.

4. Restrict to view-only

If the recipient only needs to read, don’t give them edit access. View-only removes the risk of an accidental or malicious change.

  • In Google Drive / Docs, view-only also enables settings to prevent download, print, and copy (best-effort, easily defeated by screenshots, but raises the effort bar).

5. Turn on access logs

For anything genuinely sensitive:

  • Google Drive (Workspace) — activity dashboard shows who viewed a file.
  • OneDrive for Business — access reports.
  • Dropbox (paid tiers) — event log.

Free consumer tiers often do not expose this. For consumer-grade sensitive sharing, the alternative is to use a provider that does.

The recipient problem: they won’t install anything

A large share of the people you need to send files to will not sign up for a new account, let alone install a new app. Here are the options ordered from simplest to most secure:

Option A: password-protected PDF, out-of-band password

The fallback that works with almost anyone. See Password-protected PDFs, done right. The recipient needs nothing — just a PDF reader. You deliver the password over SMS or a phone call.

Useful for: single-document, one-off sharing with someone who is comfortable with email and nothing else.

Option B: a standard cloud share with expiry and a password

If they’re willing to sign in to a Google, Microsoft, or Apple account to view the file (most people already have at least one), this works well. Share to a specific account, with an expiry date, and a link password if the provider supports it.

Useful for: most accountant / lawyer / contractor workflows.

Option C: a secure client portal

If you run a professional practice (legal, medical, financial) where you share sensitive documents regularly, running a client portal is worth the effort. Products like Content Snare, Clio, or a practice-specific portal give the client a stable place to upload documents, with proper logging and access controls.

Useful for: practices with recurring sensitive exchanges. The setup effort pays off across many transactions.

Option D: ephemeral sharing services

Services like Firefox Send (discontinued, but open-source clones exist — PrivateBin for text, OnionShare for files) let you send a one-time, ephemeral link. Technical but powerful for genuinely sensitive transfers.

Useful for: high-sensitivity, technically-literate recipients.

sharing

Proton Drive and Tresorit both offer the ability to share a file via a link to someone who doesn’t have an account. The link URL contains the decryption key (in the URL fragment, which doesn’t travel to the server), so the provider cannot read the file. The recipient opens the link and sees the plaintext.

Useful for: when the file is sensitive and you want the provider itself unable to read it.

A workflow to standardize on

For a solo practitioner or small business, a workable pattern is:

  1. Default — share via the paid tier of one of the big cloud providers, with: specific recipient account, 7–30 day expiry, a password on the link where supported, and view-only access.
  2. If the recipient won’t log in — fall back to a password-protected PDF with the password sent by SMS.
  3. For very sensitive files — use an E2EE provider (Proton Drive, Tresorit) with link sharing.
  4. For repeat clients — invest in a client portal once, use it for everyone.

The goal is not to have one tool for every case; it’s to have a simple tree of “if… then use…”. When the first step is the default, the rest is a short escalation.

An annual audit

On every cloud account you use, once a year:

  • List every shared link.
  • Disable any that are older than their intended purpose.
  • Confirm anything still active has an expiry set.
  • Confirm the recipient list is still accurate.

Fifteen minutes. The alternative is a five-year-old public share containing client tax returns, which was a real incident for somebody’s accountant in roughly every month of the last decade.

Sources

  1. Google — Share files from Google Drive
  2. Microsoft — Share OneDrive files and folders
  3. Dropbox — Set a link expiration date
  4. Cloud Security Alliance — Data Security and Information Lifecycle Management