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.
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.
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.
The highlighted half is the fragment. Browsers keep it to themselves — it is not sent to a server, a proxy or a log.
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.
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.
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.
This build has no relay to inspect. The network tab stays empty because nothing is sent — not because something clever is happening.
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.
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.
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.