Is a transfer link secure enough for client work?

Every file transfer service works the same way: it gives you a long unguessable URL and treats anyone holding it as authorised. That is weaker than a password and much stronger than most people assume. Understanding exactly what it does and does not protect is the difference between using it sensibly and either worrying about the wrong thing or not worrying at all.

What a download link actually is

The technical term is capability URL: the link is the permission. There is no login because the address itself is the secret. A well built one has enough randomness that guessing it is not a realistic attack, in the same way that guessing a password is not.

What that buys you: nobody browsing the service can find your transfer, there is no directory to enumerate, and the storage behind it is not publicly listable. What it does not buy you: any protection at all once the link is out of your hands. Forwarded, pasted into a group chat, or left in an inbox that later gets breached, and it works for whoever has it.

Two things turn that from a weakness into a manageable one. Expiry puts a ceiling on how long a leaked link stays useful. Deletion means that after expiry there is nothing to leak. A service that keeps files indefinitely has neither.

Where the risk actually sits

In descending order of how likely it is to be what actually goes wrong:

• The client forwards the link. By far the most common. Usually harmless, occasionally not, and entirely outside your control once you have sent it.
• The link sits in an inbox forever. If it never expires, it is a permanent copy of a client's wedding in an email account with a reused password. Expiry is what closes this.
• You sent it to the wrong address. A typo in a recipient field. An expiry you can set to one hour limits the damage.
• The service is breached. Real but rare, and much less likely to matter if the files were deleted three days after delivery.
• Somebody guessed the URL. Effectively never, with a well generated code.

Notice that four of the five are about how long the files exist, not about encryption. Retention is the security control that does the most work here, and it is the one photographers think about least.

Four questions to ask a service

Before a client's wedding goes through anything:

1. When exactly are the files deleted, and can I choose? A named window is a commitment. "We may retain files" is not.
2. Is the storage private, and is the download link time limited? The right answer is a signed URL that stops working, not a public bucket path that works forever.
3. Who else touches the files? A privacy policy that names its sub-processors is doing the honest version of this. Vagueness here is the tell.
4. What happens to my email address? Ask specifically whether it joins a marketing list. Plenty of free tools treat the delivery address as a lead.

For what it is worth, Kepla File Transfer answers those as: you choose one hour to three days and the files are deleted at that point with no grace period, the bucket is private and every download is a fresh signed link that cannot outlive the transfer, the sub-processors are named in the privacy policy, and sender addresses are kept in their own table and never added to any mailing list.

Practical rules for client work

None of this requires a security policy document. Four habits cover it:

• Match the expiry to the sensitivity. Three days for a public wedding gallery. One hour for a boudoir set. The shorter window costs you nothing if the client is expecting it.
• Tell the client the link expires, in the message, with the date. It converts a security control into a reason to download promptly.
• Strip location metadata from anything shot at a home. The link expiring does not help if every frame carries the address. The metadata remover runs in your browser.
• Do not use a transfer link as an archive. It is designed to disappear. Keep your own copies.

FAQ