Zero Trust, Explained — Open Arbitration

1. Plain language

The short version

Only you can read your case content. Not Open Arbitration staff. Not anyone we might hire later. Not a future buyer of the platform. Not anyone who serves us with a subpoena. Our servers only hold scrambled data, and we do not have the key.

The trade-off, said plainly: if you lose your password and your recovery code, your case content is gone forever. We cannot recover it. No one can. That is not a bug in the system — it is the whole point of the system. We built it so that losing both keys is the only way your data can end up exposed.

Recovery code warning. At registration we give you a one-time recovery code. Download it and store it safely. If you forget your password and lose the recovery code, your encrypted content becomes permanently unrecoverable. No one at Open Arbitration can restore it. This is the correct outcome of an end-to-end encryption design.

Why we designed it this way

Open Arbitration handles some of the most sensitive moments in people's lives — billing disputes, workplace conflicts, medical situations. We built it so we genuinely cannot read your case content, not just that we promise not to.

A platform that could read that data — even accidentally, even under legal compulsion, even with the best intentions — would make itself part of the problem. We'd rather make a hard promise we can actually keep.

What zero trust means here

Most websites promise to protect your data. That promise depends on their security working, their staff behaving, their servers never being breached, and no court ever compelling them to hand it over.

Open Arbitration promises something different: we can't read your data in the first place. The content you type and the files you upload are scrambled inside your own browser before they ever reach us. We receive, store, and return sealed boxes. Only your device holds the key that opens them.

In one sentence: you hold the only key. We hold sealed boxes and cannot open them.

2. How it works

Think of your case data as a safe. The safe sits on our server. We can copy the safe and move it around, but we can't open it.

Two keys can open the safe:

Your password — the one you use every day. The fast, convenient key.
Your recovery code — a long one-time code you save when you sign up. The emergency spare.

Either key on its own is enough. Lose one, use the other to set a new password. Lose both, and the safe stays closed forever.

Here's what happens at each moment:

When you sign up — you choose a password. Your browser generates a one-time recovery code and shows it to you. You must save it. Both the password and the recovery code stay on your device only — we never see either.
When you log in — you enter your password. Your browser uses it to unscramble your data. We only see scrambled data going in and out.
When you change your password — your data doesn't need to be re-scrambled. Only the password that unlocks it changes. Fast.
When you forget your password — you verify your email, enter your recovery code, and set a new password. You're back in.
When you lose both — there is no step here. The data is unreadable by anyone, including us.

3. What we see

This distinction matters. We encrypt the things that are about your dispute. We don't encrypt the things that let the platform function.

Protected (scrambled before leaving your browser)

Your description of the dispute
Notes you take on your case
Messages and letters, including anything you've drafted
Labels you put on documents
Every file you upload

Not protected (stored as regular readable text)

The name of the company you're disputing
The type of claim (billing, employment, product, etc.)
Dates and timestamps
The stage your case is in
The dollar-amount range (e.g. "$500–$2,500")

We need the second list to run the platform, route your case, and publish aggregate research on arbitration patterns. We don't need the first list — so we don't keep a readable copy of it.

A row-by-row answer to "can Open Arbitration read this?"

Data category	Can OA read it?	Why
Company name, stage, claim type, dates, amount range	Yes	Used for service operation and aggregate research on arbitration patterns.
Wrapped master key (opaque ciphertext)	Yes, but useless	Without your password, we cannot unwrap it.
Dispute description, notes, messages	No	Encrypted in your browser before upload. Every protected field is padded into fixed 256-byte buckets and always stores ciphertext — even when you left it blank — so a database observer cannot tell which optional fields you entered and cannot infer the exact length of your text.
Document labels, drafted letters, uploaded files	No	Encrypted in your browser before upload.
Your password, master key, recovery code	Never exist server-side	Generated and used only in your browser.

4. Key lifecycle

Five flows describe every moment a key is created, used, or replaced.

Registration

You pick a password.
Your browser generates a random recovery code and shows it to you.
Your browser derives two keys: a master key from the recovery code, and a wrapping key from the password.
Your browser wraps (encrypts) the master key with the wrapping key.
Our server receives only the wrapped master key and the password hash. It never sees the master key, the wrapping key, or the recovery code.
You are required to download your recovery code before continuing.

Normal login

You enter your password.
Server validates the password hash and returns your wrapped master key.
Your browser re-derives the wrapping key from your password, unwraps the master key, and holds it in memory for the session.
On logout, the master key is wiped from your browser.

Password change

You enter the current password — browser unwraps the master key.
You enter a new password — browser derives a new wrapping key and re-wraps the master key.
Server atomically replaces the wrapped master key and the password hash.
No case content is re-encrypted because the master key itself did not change.

Forgot password

You verify your email.
You enter your recovery code — browser derives the master key directly.
You set a new password — browser re-wraps the master key with the new wrapping key.
Server atomically replaces the wrapped master key and the password hash.

Both credentials lost

There is no path to the master key. Your encrypted content is permanently unreadable. Plaintext metadata is preserved. We disclose this outcome at registration.

5. Threat model

Concrete scenarios, in the order people usually worry about them.

What if…	What we've done
Our servers get hacked?	The attacker gets sealed boxes. Without your password or recovery code, nothing inside can be read.
Someone steals the file we store that's linked to your account?	Useless without your password. It's scrambled data, not a key.
An Open Arbitration employee goes rogue?	There is no employee path to your content. The key that unlocks it does not exist on our servers. No admin override. No master key on our side.
A court orders us to hand over your case data?	We can only produce the scrambled version. We do not have what's needed to unscramble it.
Someone steals your recovery code?	They still need access to your email to use it. The recovery code alone cannot take over your account.
Someone steals your logged-in session?	The ability to decrypt your data only exists in your browser's memory while you're logged in. Your connection to us is encrypted the whole time.
Your password is weak?	We deliberately make password-checking slow. An attacker has to spend meaningful computing time on every single guess — trillions of guesses is not practical.
Someone tries to guess your recovery code?	Recovery codes are long random values. Guessing them is mathematically infeasible — not difficult, infeasible.

6. Technical background

For the developer-curious, security-minded, or anyone evaluating the platform.

Cryptographic primitives

Field and file encryption: AES-256-GCM
Key derivation: PBKDF2-SHA256, 600,000 iterations
Authentication hash (separate from encryption): BCrypt
Randomness: crypto.getRandomValues via Web Crypto SubtleCrypto

Wrapped-key architecture

RecoveryCode ──PBKDF2──▶ MasterKey (256-bit)
                          └─ encrypts all case content

Password     ──PBKDF2──▶ KeyEncryptionKey (256-bit)
                          └─ wraps the MasterKey only

The server stores WrappedMasterKey = AES-256-GCM(KeyEncryptionKey, MasterKey) as an opaque blob. The MasterKey itself never changes after account creation. Changing your password re-wraps it; it does not re-encrypt a single byte of your case data.

What the server holds, and what it never holds

Stored on server	Never on server
KDF salts (salts are not secret)	MasterKey
`WrappedMasterKey` (opaque ciphertext)	KeyEncryptionKey
BCrypt password hash (authentication only)	RecoveryCode
Plaintext metadata (company, stage, dates)	Plaintext case content

Field encryption detail

Every encrypted field is stored as Base64(IV ‖ Ciphertext ‖ AuthTag):

IV: 96-bit, freshly random per write
Associated data: the CaseId (or DocumentId for files) is bound to every encryption operation via AES-GCM's additional-authenticated-data input. Ciphertext from one case cannot be transplanted into another and still decrypt successfully.

Client-side only — no server decryption path exists

All encryption and decryption happens in the browser. There is no server-side code path that can produce plaintext from stored ciphertext. There is no admin override, no key escrow, no master override key.

A full compromise of our database gives an attacker sealed boxes plus the salts used to derive each user's keys. Nothing else. They would still need to brute-force a 600,000-iteration PBKDF2 against each user's password — per user, per salt.

Recovery-code reset requires email verification

A stolen recovery code alone cannot take over an account. The server requires a verified-email session before it will accept a new WrappedMasterKey. The recovery code proves you can decrypt; email verification proves you control the account.

Architectural guarantee: this is not a promise we could break. The master key does not exist on our servers. A policy change, a subpoena, or a compromised employee cannot produce content we never received in readable form.

Questions about the security model? The full architecture is published in our open specification.