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
| Data | Collected when | Why |
|---|---|---|
| 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:
- Plaintext content of anything you encrypt or decrypt
- Private keys — generated and held in your browser only, never transmitted
- The real filename, file type, or file size sealed inside a
.cellpayload - Who sent a given encrypted blob — there is no sign-in at all on the send path
- For a plain link (not limited to recipients): who it is for, or who downloaded it
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
- Encrypted blobs — deleted at whichever comes first: the TTL you chose (1h/1d/7d) or, if you marked it burn-after-read, the first successful download.
- Login links — single-use, expire quickly, and issuing a new one immediately invalidates any unused previous one for that address.
- Sessions — expire automatically; you can also sign out at any time.
- Rate-limit hashes — rotate daily and are tied to a value that resets on every server restart, so they don't accumulate into a long-term record.
- Directory listings — kept until you remove them, or until the expiry you set on that listing (if any) passes.
- Download receipts and delivery logs — 30 days by default. Where a party to
a delivery is under industry record-keeping rules (an accounting, legal or healthcare practice
that declares it, or a verified license), they are kept as long as the strictest of those rules
requires — up to 7 years — fixed when the delivery is made. The published policy is in
/.well-known/cd-cert-broker.json. - License verifications — the badge lapses when the license expires; the application record is kept for audit until you ask us to delete it.
- Abuse-report evidence — deleted when a report is dismissed; otherwise held 90 days, or one year when it has been reported to the authorities.
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
| Service | What 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 Service | Carries 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
- Never publish a key or sign in, and no email is ever collected from you.
- Remove a directory listing at any time (via the unpublish flow, or by asking us — see below).
- Ask us to delete your email and listing history entirely.
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.