Privacy — CloakDrop

The short version

No network requests. This page makes none at all — no analytics, no CDN, no third-party fonts, no tracking pixel. One thing is not ours to switch off: Cloudflare attaches a network-error-reporting policy to every response, so your browser may report a failed connection to a.nel.cloudflare.com. It carries the address and the error, never a file, a filename or a key — and successful loads are not reported at all.
One cookie, and only while the site is closed. The access PIN sets cd_gate so you are not asked again for a week. Nothing else here sets or reads one.
One localStorage key. It remembers which theme you picked. Six more from earlier builds are listed below — nothing writes them any more.
Two IndexedDB stores. They hold your encrypted drops, and nothing else.

Those four points are the whole story, and you do not have to take them from us. Open your browser’s network tab and reload this page: nothing is requested. The two typefaces are embedded in the file itself, which is most of why it is so large. The verify page walks through checking the rest in dev tools.

Everything this site stores

All of it sits in your browser, under this site’s origin. None of it is transmitted, because there is nowhere to transmit it to.

Cookies

One, and only for as long as CloakDrop is closed to the public. The page that asks for the access PIN sets cd_gate once you enter it correctly, so that you are not asked again for seven days. It holds an expiry date and a signature over that date — no identifier, nothing that describes you, and nothing that outlives the date. It is HttpOnly, so no script on this site can read it, and it is sent to this origin and nowhere else.

The status board at status.cloakdrop.com runs the same wall while the site is closed and sets its own cd_status for the same seven days, with the same properties. It is a separate host, so it is a separate cookie.

Nothing else here sets or reads a cookie. Both belong to the wall in front of the site rather than to the site itself: once the wall is gone, so are they.

localStorage

One key, and it is not an identifier. It holds no name, no address and nothing that describes you — it records which theme you picked. Earlier builds wrote six more, for screens and switches that are no longer part of this site.

cloakdrop-theme — auto, light or dark. Written when you choose a theme, and read on every page load before anything is painted, so the page does not flash the wrong colour at you.
Left over from earlier builds, written by nothing today. cloakdrop-default-expiry, cloakdrop-burn, cloakdrop-received-cleared, cloakdrop-side-collapsed and cloakdrop-dense belonged to a settings screen and a drop overview that are no longer part of this site. cloakdrop-consent belonged to a cookie banner that asked consent for analytics which never existed; that banner is gone too. Nothing here reads or writes any of the six. If your browser still holds them, clearing site data removes them.

Clearing site data for this origin removes the key and any leftovers. Nothing else on this site writes to localStorage.

IndexedDB

The database is called cloakdrop, version 1, and it has two stores. It is created the first time you cloak something or open a drop link; if you have done neither, it is not there at all.

transfers, keyed by the 12-character transfer id. Holds the encrypted manifest, the 8-byte IV prefix, the timestamp the drop was created, the moment it stops opening, and the total size in bytes. The last one is there so the list of stored drops can show you what is on your disk without the key — it reveals nothing that counting the chunk rows would not already tell someone with access to your profile.
An optional label you can type in the overview. It is the one field here that is not encrypted, because its whole job is to be readable without the key — so write what tells two drops apart, not what is in them. Empty unless you fill it.
chunks, keyed by <id>:<n>. One row per chunk, up to 4 MB each, numbered from one. Be precise about what this gives away: each row is the exact length of its plaintext plus a 16-byte tag, so anyone who can open this browser profile can read the size of every file in the drop to the byte. Not the name, not the type, not the content — but the size.

Two more things this build does that you should know about. It asks the browser for persistent storage the first time you create a drop — that is a request not to clear the encrypted pieces when space runs short, and the browser is free to refuse it. And when a drop is deleted, the browser decides when the freed space is actually reclaimed; the row is gone immediately, the reported disk usage can lag behind for a while. Neither sends anything anywhere.

What is readable in there, and what is not

The manifest holds the filenames, sizes and MIME types, and it is stored as ciphertext — encrypted under the same key as the files, with the counter half of the IV set to zero. It sits inside the transfer record, not in the chunk store. Two things beside it are not encrypted: the timestamp the drop was created, and the 8-byte IV prefix. Neither reveals anything about the contents, but the timestamp does say when you used the app.

The number of chunk rows is also plain to see. Anyone with access to your browser profile can count them and learn roughly how large a drop is, without being able to read a byte of it.

The password, if you set one

A drop can carry a password. It is never sent anywhere, never stored, and never leaves the tab you typed it in — there is nowhere for it to go. What it does is change what the link contains: without a password the link carries the key itself, with one it carries the key wrapped under a second key derived from your password (PBKDF2-SHA256, 600,000 rounds, with a random salt that rides in the link because it is not a secret).

Nobody can recover it, including whoever runs this site. There is no reset, no hint, no copy. If it is lost the encrypted pieces stay on the disk and open for nobody — that is not a shortcoming, it is the whole mechanism.

Expiry is a check. Deleting is separate, and real.

Every drop carries the moment it stops opening — one hour, twenty-four hours or seven days after it was created, whichever the sender picked. That is a comparison against the stored timestamp and nothing more: when it passes, the link refuses to open, and the encrypted chunks are still on your disk. A short expiry hides a drop sooner; it does not erase anything.

Erasing is a separate button. Delete this drop after cloaking, and Delete from this browser after opening one, remove the transfer record and every one of its chunks from IndexedDB in a single transaction. That is a real deletion: afterwards the link cannot be made to open again, here or anywhere, because the ciphertext it points at is gone. Nothing is asked first and nothing is sent anywhere — the button deletes rows in your own browser.

Once a drop is past its time, the app deletes it — record and every chunk — the next time you open it. That is the only thing here that removes data on its own, it happens entirely in your browser, and nothing is sent anywhere in the process. Until that next visit the pieces are still on your disk, so expiry is not an instant shredder.

Drops that have not expired stay until you delete them or clear site data. Nothing removes those on a schedule, and no page will tell you otherwise.

The contact form

The form on the contact page composes a message and hands it to your own mail client. Nothing is transmitted by this page. Once you press send in your mail app, ordinary email applies: your provider, ours, and everything in between handles it the way it handles all mail. Encrypted transfer between servers is normal but not guaranteed, and neither of us controls that.

Do not paste a drop link into it. The part after the # is the decryption key, and mail is the wrong place for it.

There is no account

Nothing on this site signs you in. There is no registration, no password, no session and no recovery, because there is no account server for any of that to talk to. The dashboard and settings screens are interface, not access: everything they keep is in the preference keys listed above.

The practical consequence is worth saying plainly: a drop lives in the browser that made it. Open the same link somewhere else and there is nothing to find, because the encrypted chunks never left the machine they were written on. Carrying them between people is exactly what the relay is for.

What this page does not know about you

No analytics. No page views, no events, no session recording, no heatmaps, no fingerprinting. Not switched off somewhere — simply absent.
No third-party anything. No CDN, no external stylesheet, no external script, no embedded video, no tracking pixel, no social widget. The two typefaces are base64 inside the file, which is why no font server ever sees you.
No contents of your files. Encryption happens in your browser before anything is written anywhere, and the key is generated there and never sent.
No IP address, from this page. The page itself makes no requests at all.

The one thing outside this page’s control

Whoever serves this file sees the request for it, the way every web server does: your IP address, the time, the page you asked for, and your browser’s user agent. That is a property of the host, not of this code, and it is one of the details still open at the bottom of this page.

What a relay will change

Nothing in this section happens today. The relay being built will put a server between two browsers, so that a drop can reach a device that did not create it. Such a server necessarily sees more than nothing, and it is worth being precise about how much before it exists rather than after.

What it will see

Ciphertext, and the plaintext IV prefix that goes with it.
The total size and the number of chunks, which together approximate how much you sent.
Transfer times, and the IP addresses of both ends.

What it will not see

Filenames, file types and file contents. Those are inside the encrypted manifest and the encrypted chunks.
The key. It lives after the # in the link, and browsers do not send that part of a URL to servers. That is the whole design.

Until that server exists, the sections above are the complete list, and this section is a description of a design rather than of a deployment.

Your rights

Under the GDPR you have the rights below. They are the law’s, not ours to grant, and they apply the moment there is a controller processing your data.

Access. Ask what is held about you. Today the honest answer is a list you can read yourself in your browser’s developer tools — the seven keys above.
Rectification. Have wrong data corrected.
Erasure. Have data deleted. Today you do it yourself, in your own browser settings; see below.
Restriction. Have processing limited while a dispute is resolved.
Portability. Receive your data in a machine-readable form. It is already in your browser: seven short strings in localStorage, and your own ciphertext in IndexedDB.
Objection. Object to processing based on legitimate interest.
Complaint. Complain to a supervisory authority. Which one depends on where the operator is established, and that is not settled yet.

Deleting everything, today

Because all of it is in your browser, you do not need to ask anyone. In your browser settings, clear site data for this origin — in Chrome and Edge this sits under Privacy and security, in Firefox under Cookies and Site Data, in Safari under Manage Website Data. That removes all seven localStorage keys and the whole IndexedDB database, including every encrypted chunk still sitting there from a drop that no longer opens.

It is also the only way to remove them. Nothing in this build deletes on your behalf, and there is nobody to ask, which is the one advantage of having no server.

What is not settled yet

A privacy policy needs a named controller to be worth anything, because the rights above are exercised against someone. CloakDrop does not have one yet. Rather than name a placeholder company, these fields are left empty:

Controller — not filled in. Name and address of the entity responsible.
Data protection officer — not filled in. Required only above certain thresholds, which this project is nowhere near.
Supervisory authority — not filled in. Determined by where the controller is established.
Hosting provider — not filled in. The one party that does see request logs.
Processors — one, and it is named: Cloudflare, Inc., 101 Townsend Street, San Francisco, CA 94107, USA. Cloudflare delivers these pages, runs the mail forwarding for hello@, abuse@ and security@, and stores the availability measurements behind status.cloakdrop.com. It therefore sees the metadata of every request — IP address, time, page — even though it never sees a file, because files never leave your browser. Processing runs on Cloudflare’s data processing addendum under Art. 28 GDPR; transfers to the United States rest on the EU standard contractual clauses.

The same gaps show on the imprint, which is where German law wants the operator named.