How it actually works

Sharing a file without handing it to us

How a share link works when even the people hosting it cannot open the file.

When you send a file through most services, something happens that nobody mentions: that file becomes readable by whoever is hosting it. Not out of malice — simply because, to hand it to someone who has no account, the server has to be able to open it.

Ours works differently, and the whole difference sits in one character: the hash mark.

What the link looks like

When you create a share link, the address you get has this shape:

lifetimecloud.me/s/<code>#k=<key>

The first half says which share. The second half, the part after the hash, is the key that decrypts the files.

Why that half never reaches us

The part of an address after the # is called the fragment, and by the way the web is built the browser does not send it to the server. Ever. That is not a promise we are making or a choice we made: it is how the protocol works, in every browser.

So when someone opens your link, all our server receives is the share code. The key stays in the recipient's browser, and that is where the files are opened.

So what do we hold?

On our disks there are the encrypted files, exactly as you uploaded them. When someone downloads, the server takes those bytes and sends them as they are: it does not open them, because it cannot.

We do keep a copy of the key in the database, but locked in turn: one locked with your own personal key, so you can find the link again six months later; and, if you put a password on the share, one locked with that password. Neither opens without something that only you or the recipient has.

With a password, the link changes shape

If you protect the share with a password, the link no longer carries the key: it becomes simply lifetimecloud.me/s/<code>. Whoever opens it has to type the password, and from that their browser derives the key that opens the files.

That is the right choice when the link travels through a channel you do not control — a group chat, a forwarded email, a message that lives on in someone else's history.

Expiry, a cap on downloads, revoking

When you create the link you can add, if you want:

an expiry in days, after which the link stops working;
a maximum number of downloads, after which it closes itself;
and at any moment you can revoke it from your list of shares.

All three checks live on the server, not in the browser: once the link has expired or the downloads have run out, the server answers that the link is no longer valid and sends no bytes, whatever the person opening it happens to hold.

One thing worth saying plainly. A link without a password works for anyone who has it: the key is inside the address. Paste it somewhere public and that file is public. The encryption protects your files from us, and from anyone who got hold of our disks — not from the person you send the link to. That is what the password and the expiry are for.

In one line

The link carries its own key, in a part of the address that never reaches our server. We keep unreadable blocks and send them on as they are. That we cannot open shared files is not a promise: it is a consequence of how the thing is built.