Threat model¶

What BlindProof protects the author from, what it does not, and why.

The threat model is also a sales asset — making it explicit builds the trust that a calm, literary audience needs before trying the product.

Threats we defend against¶

The backend is breached¶

An attacker who compromises BlindProof's servers obtains ciphertext and metadata. They cannot read any manuscript, file name, folder path, or project title — those are all encrypted under keys we do not hold.

They can see metadata patterns for enrolled users: save frequencies, word counts over time, session groupings. This is a meaningful privacy loss — an attacker could infer, for example, whether an author was currently writing or on hiatus — but not a catastrophic one. The manuscript itself remains private.

Mitigation: minimise retained metadata; encrypt path names and project titles (we do); store the Argon2id salt but never the passphrase.

BlindProof is subpoenaed¶

We can hand over ciphertext and metadata — which is all we have. The author's manuscript remains encrypted. Where legally permitted, we notify the author that their data was requested.

The author's passphrase is not derivable from anything we hold. A warrant for "the manuscript" returns an encrypted blob to the requesting party.

BlindProof goes out of business¶

Every proof bundle already produced remains verifiable indefinitely. verify.py depends only on the public OpenTimestamps calendars and on Bitcoin, both of which are independent of us and are overwhelmingly likely to outlive any individual company.

Authors can also export their encrypted data and OTS receipts in a documented format. The shutdown plan is:

1. Publish a final notice with a deadline.
2. Keep the service read-only for the notice period.
3. Provide a bulk-export endpoint for each user's raw encrypted snapshots, metadata, and OTS receipts.

Old proof bundles remain verifiable after shutdown — by the author, the publisher, any auditor.

A publisher hands a bundle to a third party and they try to extract the manuscript¶

The bundle contains commitments (HMAC-SHA256) and aggregate anchors, not the manuscript. There is no path from the bundle to the plaintext. A third party can only confirm or refute whether a specific candidate manuscript matches.

Threats we partially defend against¶

An author writes the manuscript offline and pastes it in over time, using BlindProof as theatre¶

This is hard to distinguish from legitimate drafting. The signature of paste-heavy sessions is distinctive — large atomic additions with little revision — and we can surface it in the dashboard and optionally in the proof bundle. Perfect defence is not possible without editor-plugin-level keystroke capture, which is a V1 opt-in feature.

An author generates a manuscript with AI, then scripts fake edits over months to simulate drafting¶

Partial defence. Scripted edits tend to have telltale patterns — too regular, no genuine revision, no deletion of exploratory dead ends, uniform session pacing. We compute a writing-pattern signal visible to the author (for their own information) and optionally included in proof bundles.

A sufficiently sophisticated attacker can defeat this given enough time and skill. What carries the remaining weight: the legal attestation the author signs when producing a bundle, the cost of the attack versus the reward, and — critically — the fact that BlindProof's evidence is one part of a larger chain of custody (contract, correspondence, draft exchanges). It does not have to prove authorship alone.

False positives we accept¶

An author legitimately writes drafts offline and types them up in bursts¶

A writer on holiday with a notebook, or an author who drafts by hand first, will produce paste-heavy sessions that look statistically similar to the "BlindProof as theatre" pattern above.

Mitigation: the author can optionally annotate offline periods and attach photographs of handwritten notes, which get timestamped into the same chain. Not required for the POC — and the option to produce evidence of offline drafting is itself a useful feature.

What we trust the macOS Keychain with¶

For the Mac app to resume captures at login without asking the author for their passphrase every time, the desktop helper stashes the per-account derived subkeys (enc_key and mac_key) in the macOS Keychain, scoped to the BlindProof bundle identifier and the user's login keychain.

This means: anyone who can unlock the user's macOS login session can decrypt that user's manuscripts. Concretely — someone who learns the Mac password, an attacker with physical access to an unlocked machine, or local malware running as the same user.

The alternatives are worse for a long-running capture story. Prompting for the passphrase on every login defeats the helper's reliability promise and trains authors into typing-fatigued mis-reactions. Holding the passphrase in process memory only protects against disk forensics, not against any live attacker; and it doesn't survive a reboot. The Keychain choice mirrors how 1Password, Signal, Mail.app, and every other "secrets that must be available continuously" Mac app handles the same problem — the bar set by the platform is the bar we accept.

The author's passphrase itself is not stored in the Keychain. Only the derived subkeys are. An attacker with Keychain read access can decrypt everything historically and going forward, but cannot impersonate the author to BlindProof's backend without also stealing the bearer token (separately Keychain-stashed), and cannot forge new proof bundles for the past — those are anchored.

What is deliberately out of scope¶

• Proving which human was at the keyboard. No forensic technique can do this from files alone. Conventional evidence (contracts, editorial relationship, correspondence) is what carries this part of the argument.
• Protecting against a compromised author machine. If the author's computer is hostile — e.g. malware replaces the manuscript on disk before each save — BlindProof captures the false version. This is the same failure mode any tool on a compromised host has.
• Protecting against a compromised editor. If the editor itself rewrites on save (AI copy-edit, etc.), BlindProof captures the edited version. Authors who care about exact human-keyed text must manage their tooling.

What that leaves¶

An artefact that is unforgeable backward, verifiable independently, survivable if the company disappears, and strong enough — alongside conventional evidence — to be legally credible. Not a perfect record of human cognition. A specific, bounded, cryptographic record of which file existed when.