Cellular Defense — cert broker

Privacy Policy

Last updated 2026-10-08

This service is a public-key directory and an encrypted relay for the .cell format. The short version, stated honestly rather than as a slogan: the server cannot read the documents you send through it — and neither can we. Encryption and decryption happen in your browser; the server only ever handles ciphertext. That's an end-to-end encryption guarantee, not an anonymity guarantee — this page explains the difference and exactly what we do collect.

What we collect, and why

DataCollected whenWhy
Email address Only if you publish a key to the directory or sign in to manage a listing The directory is email-keyed, like a PGP keyserver — your email is how others look up your public key. Signing in (a one-time emailed link, no password) lets you rename, expire, or remove your own listing later.
IP address Every request, transiently Used only for rate limiting. We never store a raw IP. It is hashed (SHA-256) together with a random value generated fresh each time the server restarts and the current day, then only the hash is kept. That means the same visitor's hash is unlinkable across days and across restarts — it exists only long enough to count "how many requests this hour," then becomes useless as an identifier.
Encrypted blob metadata When you upload a sealed .cell for relay Ciphertext size, a hash of the ciphertext (to verify integrity, not to identify content), an expiry time you choose (1 hour / 1 day / 7 days, or burn-after-first-download), and — optionally — a wrapper filename you type in at upload time, used only to name the download. This is not the real document's filename: that stays sealed inside the encrypted payload itself, unreadable to us, per the .cell format's own design.
Recipient key fingerprints and download receipts When a sender limits a link to its recipients (the default in the web app) The relay keeps the fingerprints of the published keys the link is for, so it can check that whoever downloads it holds one of them. It records which of those keys downloaded it and when, so the sender can see it arrived. The same fingerprints are already visible in the encrypted file's own header.
License verification details Only if you ask to have a professional license verified Your profession, licensing state, license number and name as licensed, and the practice address we copy from the public licensing registry to post you a one-time code. Only a short badge (for example "CPA · NC") is ever shown to others; the rest is kept so the verification can be audited and re-checked.
Abuse reports Only if a recipient reports something they were sent See Reporting abuse below.

What we never see

By construction — not by policy, by what the software is architecturally capable of reading — the server never has access to:

For a link limited to its recipients, we do know which published keys it is addressed to and which of them downloaded it — that is what lets the relay refuse everyone else, and what gives the sender a receipt. If a sender asks us to email the recipient, we send that email to the address their key is published under; it does not say who sent the file.

The public directory

Looking someone up by their exact email address or key fingerprint always works — that's the point of a directory. But nothing is browsable or enumerable by default: an exact-match lookup that doesn't match returns the same "not found" whether or not that email has ever used this service, so the directory can't be scraped or used to confirm who has an account.

Your email and public key become part of the browsable, listed directory only if you explicitly opt in (a "listed" toggle on your own listing). Unlisted (the default) means exact-match lookup only.

Retention

Reporting abuse

Because we cannot read what passes through the relay, we can only act on what recipients report. A report sends us that one file's encrypted copy and the key that opens that file alone — never the reporter's own key, and nothing else they have received. An administrator opens it in their own browser to review it. Reports of child sexual abuse material or malware stop the link working immediately. Where we find child sexual abuse material we are required by US law to report it to the National Center for Missing & Exploited Children and to preserve the evidence.

Third parties

ServiceWhat it handles
Maileroo (transactional email)Sends sign-in, publish-confirmation, delivery-notification and license-verification emails. Messages contain links and status only — never document content, keys or verification codes.
US Postal ServiceCarries the license-verification letter (your name as licensed, the registry's practice address, and a one-time code).
NCMEC (only if required)Receives reports of child sexual abuse material, as US law requires of service providers.
Cap (proof-of-work challenge)Gates publish/upload actions against automated abuse. Does not receive document content.
Object storage (encrypted blob storage)Stores ciphertext only — the same "never sees plaintext" guarantee applies to storage as it does to the server in front of it.

Cookies

This service does not use cookies for sessions. A signed-in session is carried in a token your browser sends in a request header, not a cookie — which also means no cross-site request can ride along with your session the way cookie-based auth can be tricked into doing.

Your choices

Contact

Questions, deletion requests, or anything else: admin@enthropicdata.com. This service is operated by Enthropic Data LLC.

Changes

If what we collect changes, this page changes with it — dated at the top. We aim to keep this page as accurate to the running code as it is today, not as a boilerplate template.

This page describes current data handling in plain terms; it is not a substitute for legal advice and is not a binding contract absent a separate agreement.