Verify a transfer

# Don’t take our word. Open dev tools.

Open the app
Read the steps

Four checks, each one something you watch happen rather than something we assert. No tooling beyond the dev tools already in your browser.

This is a preview build: the encryption is finished, and a drop opens in the browser that made it. The relay that carries drops between browsers is being built. The last section lists what these checks do not prove — that part matters just as much.

Four checks

## What you can see for yourself

Do them in order. Each one takes under a minute and needs nothing but this browser.

1

### Watch what leaves

What you do

Open your browser’s dev tools, switch to the network tab, then cloak a file at cloakdrop.com.

What you should see

Nothing leaves. No request appears at all: the encrypted drop is written to storage inside the same tab. The relay that carries drops between browsers is being built — this is the check to run on it.

2

### Read the link

What you do

Copy the link you were given and look at the part after the `#`.

What you should see

Two parameters, both base64url: `t` is the drop’s id, `k` is the AES-256 key. Both sit in the fragment, and by specification a browser never puts a fragment into a request.

https://cloakdrop.com/#t=x4Kd9pQm2Vt1&k=9fQ2mR8vJ0sT…

The highlighted half is the fragment. Browsers keep it to themselves — it is not sent to a server, a proxy or a log.

3

### Break one byte

What you do

Change a single character in the `k` half of the link, then open it in the browser that made it.

What you should see

The drop refuses to open. If you changed a character, the link is no longer 32 bytes and you get “That is not a key”; if it still decodes to 32 bytes, the tag check fails and you get “This drop did not open”. Nothing decrypts partially: AES-GCM verifies its tag before it hands back a single byte, so a wrong key fails loudly instead of producing garbage.

4

### Look at the stored record

What you do

In dev tools open Application, then IndexedDB, then the database named `cloakdrop`.

What you should see

Two stores. `chunks` holds nothing but ciphertext, keyed by drop id and chunk number, cut at 4 MB per chunk. `transfers` holds the id, an 8-byte IV prefix, a creation timestamp, the moment the drop stops opening, its total size in bytes, and the manifest — the manifest encrypted, so no filename and no file type is readable anywhere. The size is there so the list of stored drops can show you what is on your disk without the key; it gives away nothing that counting the chunk rows would not. Sizes are not hidden anyway: a stored chunk is its plaintext plus a 16-byte tag.

The honest part

## What this does not prove

Four checks are four checks. Here is where they stop — five ways.

It does not audit the code you are running

The client is not open source. Everything the app runs sits inline in a single HTML file, so view-source hands you every line — but there is no published repository to compare it against. Publishing the source is planned. Where that stands.

It does not verify a server, because there is not one

This build has no relay to inspect. The network tab stays empty because nothing is sent — not because something clever is happening.

It does not pin down what you are served next time

Nothing here signs or timestamps the page you just read. Checking it once tells you about this visit — not about the next one, and not about the copy anybody else receives.

It does not hide how much you sent

Ciphertext length gives away plaintext length, minus a fixed 16 bytes per chunk. A relay would see the shape of a drop even though it can read none of it. That is structural, not an oversight.

It does not protect a link handed to the wrong person

The key is in the link. Cryptography cannot tell a recipient from a bystander, so the link deserves the same care as the files themselves.

## The encryption is finished. The relay is being built.