You drag a folder into a browser window: a tax return, a passport scan, three years of family photos. The progress bar fills, the files appear, and the service assures you everything is "secure" and "private." Those words are doing a lot of quiet work. Whether your files are genuinely private comes down to a handful of design decisions that most providers explain only in a help page buried three clicks deep. Here is what to check before you hand over anything that matters.
Encryption: three promises that sound alike
The word "encrypted" covers at least three different setups, and they are not interchangeable.
Server-side encryption at rest. Files are encrypted on the provider's disks, but the provider holds the keys. That protects you from a stolen drive or a misconfigured backup. It does not protect you from the company itself — from staff, from automated content scanning, or from a legal request served on the business. This is the default at most mainstream services.
End-to-end or zero-knowledge encryption. Keys are derived from your password on your own device, and the provider stores only ciphertext. The company genuinely cannot read your files. The trade-offs appear later: password recovery often means permanent loss, server-side search and previews stop working, and a "forgot password" link becomes a data-loss event rather than a reset.
Encryption you control. You encrypt the file yourself — a password-protected archive, an encrypted disk image, a container you create with a reputable tool — then upload the result to any provider. This is the strongest option and the most awkward. You also own the consequences of losing the key, so keep a recovery copy somewhere offline.
Read the exact wording
"Encrypted in transit and at rest" is the weak promise; it says nothing about who can decrypt. "Zero-knowledge," "end-to-end," or a plain sentence such as "we cannot access your files" is the strong one. If a provider is vague about keys, assume server-side encryption and plan accordingly.
Sharing links leak more than most people expect
The default share setting is usually "anyone with the link." That link is a bearer token: whoever holds it gets in, whether or not that was your intention. Links get forwarded, pasted into group chats, captured in browser history, and sometimes crawled by indexing bots before you notice.
A few habits close most of the gap. Set an expiry date on every link you create. Add a password when the file is sensitive, and send the password through a different channel than the link. Prefer view-only over download where the option exists, knowing that a determined recipient can screenshot or re-share anything they can see. Revoke links when a project ends rather than trusting that nobody kept the URL.
One detail worth understanding: if a provider scans shared files for malware or generates previews on its servers, it needs the plaintext. Some services therefore apply end-to-end encryption to your private folders but fall back to server-readable storage for anything you share. Check whether sharing downgrades your protection.
Metadata: the story your files tell without being opened
Even a provider that cannot read your documents can usually see a great deal about them. Filenames alone can be revealing — "2024_medical_bills.pdf" or "resignation_letter_draft.docx" says plenty. Beyond that come file sizes, upload and access timestamps, the IP addresses you connected from, device and browser details, folder structure, and who you shared with.
Some services also generate thumbnails or run indexing so search works across your account. That processing happens server-side, which means plaintext exists on their machines at least briefly. Photos add their own layer: EXIF data can carry GPS coordinates and the exact camera model. Strip EXIF before uploading anything you would not want located, and consider neutral filenames for sensitive items.
Metadata is also what makes "we cannot read your files" a narrower claim than it first sounds. Content secrecy and activity secrecy are two different things, and most providers only offer the first.
Account deletion: what actually happens to your data
"Delete account" is rarely a single event. Ask these questions before you commit years of files to a service:
- Is it deletion or deactivation? Some services keep your data recoverable for weeks in case you change your mind. Convenient for you, and equally convenient for anyone who compromises the account.
- What happens to backups and cold storage? Live systems may purge quickly while archival copies linger for a much longer window.
- Do shared links survive? A revoked account does not always revoke file links already in circulation.
- Are old versions kept? Version history and trash folders are separate retention pools with their own timers.
- Can you export first? Test the bulk download before you need it. Discovering that a 200 GB export fails halfway through is a bad time to learn it.
- Who else holds a copy? If your account belongs to a shared team or family plan, an administrator may be able to restore or read content independently of you.
Legal retention rules vary by country and by the type of data, so treat deletion policies as a starting point rather than a guarantee. If you handle client records or regulated information, get advice from a qualified professional rather than relying on a support article.
A ten-minute audit you can run today
- Open your provider's security or privacy page and search for the words "keys" and "we cannot access." If neither appears, assume they can read your files.
- List every active share link and revoke the ones you no longer need.
- Turn on two-factor authentication, ideally with an app or hardware key rather than SMS.
- Check what your phone or desktop client syncs automatically — camera roll, downloads folder, desktop — and turn off anything you did not deliberately choose.
- Encrypt one genuinely sensitive file yourself and store it in two places, including one offline copy of the key.
- Export a small folder to confirm the process works before you depend on it.
No provider is a vault. The practical goal is to know which promises you are actually getting, to keep the truly sensitive material behind encryption you control, and to treat every share link as public until proven otherwise. Do that much and a stolen password becomes an annoyance rather than a disclosure.
Photo: anvel / Pixabay