The words, exactly as we use them.

The alphabet for the two halves of a link — the transfer id and the key — and for the IV prefix in the drop record your browser stores. It is plain base64 with + and / swapped for - and _, and the trailing = stripped.

A file is encrypted in 4 MB pieces, each one its own AES-GCM message. An empty file still produces exactly one chunk. Chunks are numbered by their IV counter, not by a byte offset.

To encrypt. You cloak files; what you get back is a drop. The site never says “upload” for what you do, because nothing is uploaded: the encryption happens in your tab, before anything else.

A set of files, one key, one link, one expiry. It is the unit everything else is measured in — size limits and expiry both apply per drop, and a drop can be deleted from the browser that holds it.

Set when you create the drop, counted from that moment and not from when the link is first opened. The default is 24 hours. Your browser checks that timestamp each time a link is opened and refuses once it has passed; the encrypted pieces are deleted the next time you open the app. Nothing revives an expired drop.
Limits

Everything after the # in a link. Browsers never transmit fragments to servers, proxies or logs — which is exactly why the key lives there.

The authentication tag AES-GCM appends to every chunk. A wrong key, a modified byte or a truncated chunk makes decryption fail loudly rather than returning something that looks like a file.
Try it yourself

The initialisation vector for a chunk: an 8-byte random prefix, fixed for the whole drop, followed by a 32-bit big-endian counter. Under one key no IV ever repeats — the one rule GCM demands.

Generated in your browser by WebCrypto, exported raw and written into the link fragment. It is never transmitted, and no copy exists anywhere else.
Security, spelled out

The encrypted index of a drop: filenames, byte sizes, types, and where each file’s chunks start. It occupies counter 0, so a file list only exists after your client has decrypted it.

An extra secret that never becomes part of the link. Without one the link carries the key itself, so whoever forwards it forwards the files. With one, the key is wrapped before it goes into the link, and the link on its own opens nothing — send the password through a different channel than the link, ideally by voice.

How a password becomes a key. Deliberately slow: every guess costs an attacker the same 600,000 rounds it costs you once. The round count follows the current OWASP guidance. A random salt travels in the link, so the same password never produces the same wrapped key twice.

What runs today. The cryptography is finished and you can try it. Drops live in the browser that created them, so a link only opens there — the relay that carries drops between browsers is being built.

The zero-egress storage that will carry drops between browsers. It is being built. By design it will hold ciphertext, an IV prefix and a timestamp — nothing readable.

The t half of a link. Nine bytes from the browser’s random source, base64url-encoded. It carries no encoded metadata; it is only an address.

The browser’s built-in cryptography API. CloakDrop uses it instead of shipping its own implementation, which is why encryption is hardware-accelerated and inspectable in your own dev tools.

Nothing readable ever leaves your device — in this build nothing leaves it at all. The term names the job the relay is being built to do: accept bytes it cannot interpret, hand them back unchanged.

There is nothing on our side that could recover your files. The consequence is blunt — lose the link and the files are gone, because no second copy of the key exists.
Fair questions