DEV Community: Alisha Albert

Sharing Confidential Documents Online? Start With an Expiry Date

Alisha Albert — Tue, 06 Oct 2026 13:30:30 +0000

Most of us send a sensitive document the same way we send everything else: as an email attachment. A signed contract to a lawyer. Tax paperwork to an accountant. Medical records to a clinic. We attach the file, type "as discussed," and hit send without thinking twice about it.

The problem is that an email attachment never really goes away. It sits in your sent folder. It sits in the recipient's inbox. It gets forwarded, downloaded onto shared drives, backed up to servers you will never hear about. Months later, long after everyone has forgotten about it, copies of your passport scan or financial statement are still sitting in inboxes that are only as secure as the weakest password protecting them.

You cannot fix that with a better password. You need a different way of sharing.

What actually makes document sharing safe

Security guides tend to throw a long checklist at you, but most of it boils down to three things.

1. Limit how long the document is available. A link that works forever is a liability. The moment the recipient has the document, there is no reason for it to still be out there. Set an expiry. Short ones — an hour, a day — for things that are time-sensitive. A few days at most for everything else.

2. Keep it off email. Once a file travels as an attachment, you lose control of it. You cannot revoke it, expire it, or even know where it ended up. A share link at least keeps the document in one place until the recipient grabs it.

3. Send access details separately. If you password-protect a PDF (which is a good habit for anything with a signature or ID number in it), do not put the password in the same email as the file. Send the link one way, the code another way. It takes thirty extra seconds and it closes the simplest attack there is: someone getting into one account and getting both.

A lighter way to do it

For a lot of everyday confidential documents, you do not need an enterprise data room. You need something between "email attachment" and "corporate security portal."

That is where view-once file sharing earns its keep. You open the site in your browser — no account, nothing to install — drop in the file, and pick how long the share should live: one hour, a day, three days, or a week. You get a short code and a QR, and the document deletes itself when the clock runs out. The file stays unlisted and encrypted while it is up.

It also fits the small realities of confidential sharing. Need your accountant to get a 200 MB folder of scanned receipts? Files go through as-is, up to 250 MB each, with no compression quietly mangling your scans. Need your lawyer to see the signed contract right now? A view-once share can delete itself the moment it is opened, so the document exists exactly as long as it needs to and not a minute longer.

A short routine that actually works

Here is the routine I would suggest for anything sensitive:

Before sending: ask whether it needs to live forever. If not, give it an expiry. Default to short.
While sending: use a share link instead of an attachment, and keep the code or password in a separate message from the link itself.
After sending: if the tool lets the share delete itself after viewing, turn that on. If not, check back and take the link down once the recipient confirms they have it.

None of this is complicated, and that is the point. The reason confidential documents leak is rarely a sophisticated hack. It is an old attachment in a forgotten inbox, or a link that someone shared three months ago and never turned off. Expiry dates and separate channels do not sound dramatic, but they close the gaps that actually get people in trouble.

The next time you are about to attach a document you would not want posted publicly, pause for the thirty seconds it takes to send confidential files with an expiring link instead. Your future self — the one not digging through sent folders wondering where that file ended up — will be glad you did.

How Freelancers Can Share Client Files Without Asking Anyone to Sign Up

Alisha Albert — Mon, 05 Oct 2026 13:54:35 +0000

Client work has a delivery problem, and it's not the work itself. It's the handoff.

You finish a project — a set of design mockups, an edited video, a batch of photos, a final PDF — and then the annoying part begins. You email it, and Gmail bounces anything over 25 MB. You upload it to Drive, and your client gets a "request access" screen because they opened it with a different account. You use a transfer tool, and the client gets asked to create an account just to download the file you already made for them.

Freelancers live in this gap. We don't need enterprise file management with client portals and permission tiers. We need something that sits between "email is too small" and "another platform my client has to learn."

After a few years of juggling this on both sides — sending work out and receiving assets from collaborators — I've found the friction usually comes down to four things.

1. Clients who won't sign up for anything

This is the biggest one. A client pays you for a deliverable, not for an onboarding flow. Asking a busy founder or a marketing manager to create an account on a tool they'll use once, verify their email, and then find your file is a lot to ask. Plenty of them just won't do it. They'll reply "can you just email it?" and then complain when the email never arrives.

2. Files that outlive the project

Most sharing links never expire. That design file from a project that ended eight months ago is still sitting on someone's server, attached to a link you lost track of. For client work — especially work under NDA — that matters. A finished project shouldn't leave a permanent copy floating around on a third-party service you can't audit.

3. Email limits that make no sense in 2026

Gmail caps attachments at 25 MB. Outlook is similar. A short phone video in 4K can be ten times that. Raw photos from a shoot, a designer's layered file, an uncompressed audio export — none of these fit in an email, and compressing them just to satisfy an attachment limit means sending your client a worse version of your work.

4. The privacy middle ground

Chat apps aren't great either. Sending client files over WhatsApp or Telegram mixes work into personal messaging, and the files stay there indefinitely unless someone manually deletes them. What you really want is a share that behaves like a handoff: you give it, they take it, and then it's gone on your terms.

What a good freelancer workflow looks like

The ideal handoff has a specific shape. You upload the file. You get something short and easy to pass along — a short code, a QR code, a link. Your client opens it on whatever device they're using, downloads what they need, and never signs up for anything. You pick how long the share stays alive, and after that it deletes itself.

That last part is worth saying twice, because it's the one most tools skip. Expiry shouldn't be a premium feature. If you're sharing a contract draft, a set of medical forms, a brand asset, or anything time-sensitive, the link should have a built-in end date. One hour, a day, a few days, a week — you choose, and the file disappears when the time runs out.

I've started using nowiretransfer for exactly this kind of handoff. It's a free tool in the browser — no account on either side. You add a file or some text, get a six-character code or a QR, and your client opens it on any modern browser. Files go up to 250 MB each and are sent as-is, so nobody is compressing your deliverable into a blurry preview. The shares are unlisted and encrypted, and you pick the expiry: one hour, 24 hours, three days, or seven days.

It works well for the usual freelancer scenarios. Sending a video cut to a client for review? A short expiry means the review link stops working once the project wraps. Need to send large files without signup, share a contract, or pass along text that shouldn't live in an email thread forever? It handles all of that from the same page. Collecting raw assets from a client who doesn't want another login? They upload from their phone browser and hand you the code.

The phone part matters more than it sounds. A surprising number of client handoffs happen on phones — a client approving a design on the couch, a collaborator sending phone photos for a project. Anything that requires a desktop app or a download is friction. Anything that works in the browser on iOS, Android, Windows, or Mac is just a link away.

A small habit worth adopting

The real win isn't one tool, it's a rule of thumb: stop creating permanent shares for temporary work. Before you send a file, ask yourself two questions. Does the recipient need an account for this? And does this link need to exist next month?

If the answer to the first is "no, but the tool demands it," use a tool that doesn't. If the answer to the second is "no," set an expiry and let the file delete itself. Your clients get their files with less effort, and you stop leaving finished projects scattered across the internet long after you've been paid.

Client work is temporary. Your file sharing should be too.

Originally published on Hashnode: https://practicalprivacynotes.hashnode.dev/how-freelancers-can-share-client-files-without-asking-anyone-to-sign-up

Stop Emailing Files to Yourself: A Lighter Way to Move Files Between Devices

Alisha Albert — Fri, 02 Oct 2026 00:49:38 +0000

How often do you email a screenshot to yourself just to get it from your phone to your desktop? Or upload a video to Drive, wait for it to sync, then download it on the other device five feet away?

We all do it. And it's absurd when you think about it — but the alternatives each have their own tax.

The friction of cross-device sharing

Apple's AirDrop is genuinely great, and completely locked to Apple's ecosystem. The moment one device is a Windows PC or an Android phone, you're back to square one.

Messaging apps work everywhere but compress media aggressively. Fine for a meme, terrible for anything you actually care about.

Cloud drives don't compress, but they make you pay in ceremony: upload, wait, manage sharing permissions, copy the link — and then the link lives forever unless you remember to kill it. For a file you needed for thirty seconds, that's a lot of overhead.

A smaller idea: the one-time handoff

Most cross-device transfers aren't storage problems. They're handoff problems. The file needs to get from device A to device B once, and then nobody needs the link again.

That's the idea behind nowiretransfer. You add a file (or paste some text) on one device and get a 6-character code. Type the code — or scan the QR — on the other device, and the file opens. No account, no app install, works in any modern browser.

What makes it different from just another cloud link:

Files go up and come down as-is. No compression, no quality loss.
Shares expire. You pick 1 hour, 24 hours, 3 days, or 7 days, and the files delete themselves when time's up. No "oops, that link from March is still live."
Private by default. Shares are unlisted — only the code opens them — and transfers are encrypted.
250 MB per file, multiple files per share.

Try it out

Next time you're about to email yourself a file, try this instead: open nowiretransfer on your phone, add the file, and open the code on your laptop. It takes about ten seconds, and there's nothing to clean up afterward.

What's actually hard about this

The interesting engineering isn't the transfer — it's the lifecycle. Expiry has to be real (bytes deleted, not just links hidden), codes have to be unguessable but typable, and the whole thing has to work on mobile browsers that love to kill background tabs mid-upload. Worth thinking about if you're building anything with shared state that shouldn't outlive its purpose.

Sometimes the best feature is the one that deletes itself.

Delete-on-read: designing a file share that destroys itself

Alisha Albert — Thu, 01 Oct 2026 20:42:55 +0000

Most file-sharing systems are built around persistence. Upload, store, serve — and keep serving until someone remembers to delete. But there's a whole class of sharing where persistence is the bug, not the feature: one-time handoffs of sensitive files.

The pattern is simple: a link that works exactly once. Here's how to think about building it.

The core mechanic: single-use tokens

At the heart of delete-on-read is a token, not a file path. The flow:

Upload stores the file and generates a random, unguessable token.
The share URL contains the token — nothing else identifies the file.
On first successful GET, the server streams the bytes, then immediately deletes the stored file (and any database record pointing to it).
Any later request with the same token returns a "gone" state.

The deletion has to happen server-side, right after the response completes. Client-side tricks — like a page that hides the link after viewing — don't count. If the bytes are still on disk, the share isn't really view-once.

A few details that matter more than they look:

Stream, then delete. Don't load the whole file into memory if you can stream it. Delete the source as soon as the stream finishes, in the same request lifecycle.
Make tokens unguessable. UUIDs or 128-bit random values. Sequential IDs are an invitation to enumeration.
Treat "viewed" carefully. If the recipient's browser prefetches or a link-preview bot hits the URL, that can burn the single view. A common fix: serve an interstitial page first ("click to reveal"), and only count the actual download/view click.

Multi-file shares: the ZIP trick

Single files are the easy case. For multiple files, the cleanest approach is to bundle them into a ZIP at share time and treat the ZIP as the single view-once object. The recipient gets one download, one deletion. nowiretransfer uses exactly this approach — you can drop several files in, and they arrive as one self-deleting archive.

Generating the ZIP on upload (rather than on download) keeps the download path simple and predictable: one stream, one delete, done.

Text shares are the same shape

The pattern generalizes nicely to text. Store the snippet server-side, hand out a token URL, render the text once, delete on first render. It's the same state machine as files — the only difference is the content type. Passwords, API keys, and config snippets are the natural use case, and they benefit from the same "no residue" guarantee.

What "deleted" should mean

This is where implementations get honest or don't. True delete-on-read means:

The file bytes are removed from storage (not just unlinked from a database row).
Backups and caches don't quietly keep a copy around past its intended life.
There's no "recently deleted" grace period that extends the exposure window.

If you're evaluating a view-once tool rather than building one, these are the questions worth asking. A tool that keeps files in a trash folder for 30 days isn't view-once — it's a file host with a countdown timer.

Why this is worth building (or using)

Delete-on-read is a small idea with an outsized effect on how people share sensitive things. It removes the whole category of "I forgot that link was still live." The UX is almost nothing — upload, share, done — because the security model is the absence of state, not the presence of more controls.

If you want to see the pattern in action, nowiretransfer is a clean example: free, no signup, files and text that delete themselves after one view, multi-file ZIP packaging. It's a good reference for how little UI this pattern actually needs.

The broader lesson: sometimes the best data retention policy is not having the data at all.