Cellular Defense

A sealed document, exactly as the server stores it

statement-q3.cell v1.4 4.2 KB
{
  "version": "1.4",
  "doc_id": "01KZMFP6S6Q8HMENXM38ADNY9A",
  "created_at": 1786320198,
  "header": {
    "threshold": { "required": 2, "of_total": 3 },
    "lifetime": { … }, "policy": { … },
    "access_map": [
      { "method": "ecdh-p256", "share_index": 1,
        "wrapped_cek":  },
      …2 more
    ],
    "payload_hash": 
  },
  "header_hash": ,
  "payload": {
    "alg": "AES-256-GCM",
    "encoding": "base64+gzip+padme",
    "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.

Encryption happens in your browser, before anything is sent. No install, no password and no plugin. Opening a file never asks you to sign in; sending one through us takes a one-click email confirmation.

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
  • Retention and disposal terms attached to the document
  • The origin the document was created on, when one is recorded
  • Integrity hashes. The sender's signature, and who the recipients are, are sealed inside

The right-hand column is metadata, and it is deliberately readable so that a .cell can be checked by someone who cannot open it. Files in the older format (1.3 and earlier) also show each recipient's key fingerprint and the sender's signing key. When you send through our relay, we also know which account sent the file: never what is in it.

The asymmetry

Confidential, and accountable

Almost every secure-file product makes both parties enrol in a portal, with passwords, before a file can move. Here nobody makes a password or installs anything, and each side gives up only what its part of the exchange needs.

The sender

Confirms an email. No password, no portal.

Look up a recipient, encrypt in your browser, send. Sending through us takes a one-click email sign-in, so that someone who sends malware or harassment can be stopped, and blocked by the people they target.

We record which account sent a file, never what is in it, and we never show it to the recipient. Rate limiting keeps no raw addresses, and the sender can choose to leave no local history of what was sent. To use no account at all, encrypt a file and pass it on yourself.

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.

Publishers sign in the same way, with a magic link, to manage their own listing: rename it, expire it, take it down. Opening a file sent to you needs no sign-in at all.

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, tax preparers and bookkeepers

Clients send tax forms, statements and ID scans from any phone or computer, with no password and nothing to install.

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.