Every developer I know is meticulous about securing their codebase — proper auth, encrypted databases, dependency audits. But the moment they need to send a quick file to a client or teammate? They throw it into whatever's convenient.
I've been guilty of this myself. And the more I've thought about it, the more it bothers me.
The word "encrypted" is doing a lot of heavy lifting
Most file sharing services advertise encryption. But "encrypted" without context is almost meaningless — there's a critical difference between in-transit encryption and end-to-end encryption (E2EE) that most people gloss over.
In-transit encryption (HTTPS/TLS) means your file is encrypted as it travels from your device to the server, and from the server to the recipient. This is the baseline — good, but not the whole picture. The file gets decrypted at the server, which means the service provider can technically access it.
Here's a rough picture of what's happening under the hood:
Client → Server: ClientHello (cipher suites, TLS version)
Server → Client: ServerHello (chosen cipher, certificate, public key)
Client → Server: ClientKeyExchange (encrypted pre-master secret)
...
[Data is decrypted and readable at the server level]
End-to-end encryption (E2EE) is the stricter standard. Your file is encrypted on your device, and can only be decrypted on the recipient's device. The server never holds the keys. Not even the service provider can read the content.
The practical question to ask any service: "Where is the data decrypted?" That answer tells you everything.
For most everyday dev tasks — sharing a build output, a log file, a quick config — in-transit encryption is probably fine. But for API keys, credentials, or sensitive client files? You want E2EE.
Files that live forever are a liability
Here's a habit worth breaking: uploading files to services that store them indefinitely.
Every file left sitting on a server is an attack surface. If that service gets breached tomorrow, your data is in that breach. Even if you shared that file six months ago and forgot about it.
The concept of ephemeral storage flips this on its head. A file that auto-deletes after download — or after 24 hours — dramatically shrinks your exposure window. For temporary assets like:
- Debug logs
- Build outputs
- Quick configs for review
- Code snippets
…there's no reason that data needs to live anywhere permanently.
When evaluating a tool, always check: What's the retention policy? Does the file disappear, or does it linger? The "less stored, less exposed" principle is simple but underused.
The rest of the security picture
Encryption and retention are the obvious ones. A few more things worth checking before you trust a service with sensitive files:
Authentication: Does it support MFA? SSO for team environments? Weak auth is often the actual attack vector, not the encryption.
Authorization: Can you password-protect a link? Restrict access to specific email addresses? See who accessed the file and when? A public link with no controls is a bet that no one else guesses the URL.
Supply chain: The file sharing app itself depends on cloud providers, open-source libraries, and third-party infrastructure. A breach upstream can expose data even if the app itself is secure. Worth asking: does the service audit its dependencies? What's their incident response plan?
What I actually look for now
After thinking through all of this, my personal checklist is pretty short:
- Is the encryption in-transit or end-to-end? Depends on the sensitivity of what I'm sharing.
- Does the file disappear after sharing? For anything temporary, I want ephemeral storage.
- Can I add access controls? At minimum, a password or expiry link.
- Is there an account requirement? For quick shares, friction kills adoption.
There are a lot of tools in this space. WeTransfer is great for large files but stores them for a week by default and collects analytics. Google Drive is powerful but adds overhead and permanence you often don't need. For quick, no-account, encrypted shares of small files (say, up to 100MB), I've been using SimpleDrop — it's a tool I've been building focused on ephemeral sharing with secure transport. No login, no ads, no lingering files. Worth checking out if that use case resonates.
But regardless of what tool you use — just be intentional about it. The five seconds it takes to ask "should this file be here permanently?" is worth it.
Top comments (0)