Cellular Defense

A sealed document, exactly as the server stores it

statement-q3.cell v1.3 4.2 KB 
{
  "version": "1.3",
  "doc_id": "01KZMFP6S6Q8HMENXM38ADNY9A",
  "created_at": 1786320198,
  "header": {
    "threshold": { "required": 2, "of_total": 3 },
    "access_map": [
      { "label": "Director A", "fingerprint": "df55f0be…",
        "wrapped_cek":  },
      …2 more
    ],
    "payload_hash": 
  },
  "header_sig": ,
  "payload": {
    "alg": "AES-256-GCM",
    "iv": ,
    "ciphertext": 
  }
  no "filename"   no "mime_type"   no "size"
}

The filename isn't in here.
Neither is the file.

A .cell carries your document as ciphertext and little else. The name, the file type and the true size are sealed inside the payload, not printed on the envelope. Whoever stores this file cannot read any of them — and neither can we.

Publish your key See how it works

Encryption happens in your browser, before anything is sent. No install, no account, and no plugin — sending and receiving never ask you to sign in.

Full disclosure

What a .cell hides — and what it plainly does not

Most encryption products publish the first column. The second one is the honest part, and you can check both yourself: open any .cell in a text editor. It is ordinary JSON.

Never in the envelope

  • The document itself — only AES-256-GCM ciphertext
  • The filename
  • The file type
  • The true size of the plaintext
  • Any private key — they are generated and stay on your device
  • Your passphrase, and anything derived from it that could be reversed

Visible to anyone holding the file

  • That a sealed document exists, and when it was created
  • How many people can open it, and how many are required
  • The label and key fingerprint of each recipient
  • Retention and disposal terms attached to the document
  • The origin the document was created on, when one is recorded
  • Integrity hashes and the sender's signature

The right-hand column is metadata, and it is deliberately readable so that a .cell can be verified by someone who cannot open it. If a recipient list is itself sensitive, use unlabelled entries — the format does not require a label.

The asymmetry

The two sides of a delivery want opposite things

Almost every secure-file product makes both parties open an account. That is backwards. Only one side of this exchange has any reason to identify itself.

The sender

Discloses nothing, signs in to nothing

Look up a recipient, encrypt in your browser, send. There is no account on the sending path and there never will be — it is the product, not a free tier.

Rate limiting keeps no raw addresses, and the sender can choose to leave no local history of what was sent.

The recipient organization

Public on purpose, because that is the point

A law office, a newsroom tip line or a compliance desk being findable is the whole value. A verified listing — address, key, published fingerprint — reads like a bar number or a masthead.

So the only sign-in anywhere is a magic link for publishers, used to manage your own listing: rename it, expire it, take it down.

Said plainly, and no further: the server cannot read your document, and neither can we. That is end-to-end encryption. It is not anonymity, and we don't sell it as such.

What you can do with it

Delivery rules that survive the recipient

Quorum

Require two people to open one document

Split access k-of-n: a wire instruction that opens only when the CFO and outside counsel are both present. Dual control on the document itself, not on the inbox it landed in.

Hardware keys

The YubiKey is the key

Unlock with a hardware security key or the fingerprint reader already on the device. The secret is generated on the key and never leaves it, so there is nothing on our side to hand over or lose.

Disposal

Retention terms, with the enforcement stated honestly

Disposal rules run on the operator's side and are genuinely enforced. Retention hints travel with the file as advisory — and the format says so in as many words, because nothing can be enforced against someone who already holds the key.

Lineage

Rotate a key without breaking the chain

Re-sealing a document links the new envelope to the previous one by hash, so a file's history stays auditable across key rotations and staff changes.

Built for

People who email things they shouldn't email

Confidentiality duties, ordinary staff, no security team. The adversary is a breached mail account or a curious IT department — not a nation-state.

Law firms

Settlement terms and client records, sent without a portal the client has to enrol in.

CPAs and tax preparers

Stop emailing SSNs and bank details. Clients send documents in without an account.

Title and escrow

Wire instructions under dual control — the direct answer to wire fraud.

Ethics and whistleblower intake

Confidential reporting for organizations that will never run a newsroom's tooling.

What each of these looks like in practice →

Don't trust us

Every claim on this page is checkable

The format is published, the browser code is readable, and the specification is timestamped. We would rather be audited than believed.

The specification

The normative format spec, published as a defensive disclosure. No patent is asserted against it.

An independent verifier

A checker written from the spec alone, sharing no code with the product, so it can prove the product honest.

Bitcoin-anchored timestamps

The published spec bytes are anchored on-chain, so the version you read is the version we froze.

Read the spec Publish your key