Your Unpublished Manuscript Is Sitting in Plaintext. Here's Why That Should Bother You

For nearly every cloud writing tool, the honest answer is: the vendor, any employee with database access, anyone who successfully compromises them, and — depending on a paragraph in a terms page almost nobody opens — a model training pipeline.

That is a perfectly reasonable arrangement for a shopping list. It is a meaningfully different proposition for an unpublished novel, a memoir about people who are still alive, a book written under NDA, or a diary.

Key takeaways

• "Encrypted" is the most abused word in software marketing. TLS in transit and disk encryption at rest both leave the vendor holding a key.
• The one diagnostic question: can the vendor reset your password and give you your content back? If yes, they could always read it.
• The risk is not usually a dramatic breach. It is account suspension, policy drift, legal process, and acquisition.
• Zero-knowledge has real costs — you own your credentials, and live multiplayer editing is off the menu.
• AI processing is a separate question from storage. Any vendor blurring the two is worth a follow-up question.

What most tools mean by "encrypted"

Three different things travel under one word, and only one of them changes who can read your book.

Encryption in transit (TLS). Your text is protected between your machine and the server. Universal, necessary, and irrelevant to this question — it protects against someone on the coffee shop wifi, not against the company at the other end.

Encryption at rest (disk-level). The disks in the data centre are encrypted. This protects against someone physically stealing a drive. The application still reads your plaintext all day, because it holds the key. This is what the overwhelming majority of "your data is encrypted" claims mean.

End-to-end / zero-knowledge encryption. Your text is encrypted on your device, with a key the server never receives. The service stores ciphertext it cannot decrypt. This is the only one of the three that changes the answer to "who can read my manuscript."

The test that cuts through all the marketing:

Can the vendor reset your password and give you your documents back?

If yes, they can read your documents. Always could.

That is not a gotcha; it is arithmetic. Restoring access to content requires the key. Password reset flows that restore content prove the key was available to the vendor all along.

The risks that actually happen

The imagined risk is a hacker. The real ones are duller and considerably more common.

Account suspension. Automated systems suspend accounts, appeals go to a form, and the form goes nowhere. People have lost a decade of work this way for reasons never explained. Encryption does not prevent this — you should still hold your own backups — but it does mean the suspended copy is unreadable to whoever inherits it.

Policy drift. The terms you agreed to in 2021 are not the terms you are under now. The specific paragraph to watch is any variant of "we may use your content to improve our services," which is broad enough to include training data and frequently arrives by email notification you did not read.

Acquisition. Your data is an asset in the sale. The privacy policy of the acquiring company is the one that will apply, and you were not consulted.

Employee access. Not malice, usually. Support staff debugging a sync issue can generally see documents. Most companies log this. Very few writers know it is possible.

Legal process. A subpoena to a company that holds plaintext produces plaintext. A subpoena to a company that holds ciphertext produces ciphertext. This matters for journalists, memoirists writing about living people, and anyone writing about a jurisdiction they live in.

Model training. The one authors ask about most. The honest position is that policies vary widely, change often, and are usually written to permit more than they advertise. Consumer tiers are much more permissive than business tiers of the same product. We have written before about what crawlers and AI vendors do with text they can reach; the same reasoning applies with more force to text you handed over voluntarily.

None of these is a reason to panic. All of them are reasons to make the choice deliberately rather than by default.

How client-side encryption actually works

The mechanics, briefly, because "we encrypt everything" deserves specifics.

Layer	What a zero-knowledge design does
Where encryption happens	In your browser, before anything is transmitted
What the server stores	Ciphertext only
Key generation	On your device
Key scope	Per project, so one book's key never unlocks another
Key storage	On your device, not on the server
Recovery	A recovery passphrase you hold — not a support ticket
Sync	Encrypted blobs move between devices; the server routes what it cannot read

The per-project scoping is a detail worth noticing. It means a compromise of one key is a compromise of one book, and it lets you share a single project without handing over the vault.

This is the architecture CipherWrite is built on, and the full technical argument is on its own page rather than compressed into a feature bullet — which is itself a reasonable thing to expect from any vendor making the claim.

The two honest costs

An encrypted writing app is a trade, and anyone who tells you otherwise is selling.

You are genuinely responsible for your credentials. There is no support desk that can rescue you, because a support desk that could rescue you could also read you. This is the price of the guarantee, not a gap in the product. It is why the recovery passphrase and recovery questions exist, and why they are worth setting up on day one rather than day two hundred — and why you should still keep exported backups somewhere else, as you would with anything you cannot afford to lose.

Real-time multiplayer editing is effectively off the menu. Live shared editing and zero-knowledge encryption pull in opposite directions, and no roadmap resolves that cleanly. If your workflow is a Google-Docs-style writing room with three co-authors typing simultaneously, this is the wrong tool and privacy is the wrong priority for you. That is a legitimate position.

There is a third cost that is not really a cost but does surprise people: search is harder. A server that cannot read your text cannot index it, so search has to happen on your device. In practice this is fine, and it produces some genuinely interesting downstream design consequences — see below.

The interesting part: what the constraint forces

The thing nobody expects about building on encryption is that it makes some products better by making the lazy version impossible.

Consider an AI accountability feature. The obvious implementation indexes your manuscript on the server, embeds it, and asks a model about your plot. Under client-side encryption that is simply not available — there is no readable manuscript to index.

So CipherWrite's accountability agent, The Finisher, remembers something else instead: a small, consented, plaintext profile of the writer. Why you started this book. Where you stalled last time. What got you moving again. Eight closed field paths, updated by patch operations so an update cannot silently erase what you said on day one, with a memory viewer and one-click wipe available on the free tier as well as Pro — data rights deliberately not behind the paywall.

That is a better product than the indexed version, and it exists because the shortcut was closed. It knows your pattern rather than your plot, and the pattern is what decides whether the book gets finished. The full argument is in why most novels die in the middle.

The same thing happened with outlines. Since the outline could not live as scaffold chapters inside an indexed manuscript, it became its own encrypted document — which incidentally solved the older, more mundane problem of beat notes polluting the draft, the word count and the export. And an outline is arguably the last thing that should sit in plaintext: it names your ending in a hundred words.

Where encryption stops, and saying so

This is the part where most privacy marketing quietly overreaches, so it is worth being blunt.

Encryption at rest is not encryption during processing. When you deliberately send a chapter to an AI feature, that text has to be readable by the model to be analysed. There is no way around that with today's technology, and any vendor implying otherwise is describing something that does not exist.

What differs between vendors is scope and default. In a plaintext product, everything sits readable on the server permanently, and AI processing is just one more read. In a zero-knowledge product, the vault is unreadable by default and text leaves it only when you take a deliberate action.

CipherWrite's own line here is worth quoting because it is the pattern to look for: the encryption claim covers the editor, the story bible and the Blueprint. It explicitly does not claim "never stored, never trains AI" for the AI Writing Coach, which necessarily sends submitted text to a model and saves submissions to your account so later lessons can build on earlier ones. That limitation is stated in the coach's own privacy FAQ rather than buried.

A vendor who tells you where their guarantee stops is giving you more information than one whose guarantee covers everything.

A checklist for any writing tool

Apply this to us, to your current tool, to whatever you are considering:

1. Can they reset my password and restore my content? If yes, they can read it.
2. Where does encryption happen — my device or their server? Only the first one counts.
3. What exactly does the AI feature send, and what is retained afterwards? Ask for specifics; vagueness is an answer.
4. Is my text used for training? Check the current policy, and check which tier you are on.
5. Can I export everything, in a standard format, right now? A privacy tool you cannot leave has replaced one lock-in with another.
6. What happens if I lose my key? A good answer is a recovery passphrase you hold. A great answer includes "and here is how to test it today."
7. Who else has been given access? Employees, subprocessors, analytics vendors.

Most tools fail question one immediately. That is not necessarily disqualifying — it is a trade you might reasonably accept — but it should be a decision rather than an assumption.

So does it matter for you?

Honestly: sometimes not.

If you are writing a cosy mystery you intend to publish next year, the realistic worst case of a plaintext tool is that a company you have never met holds a copy of a book you are about to give the world anyway. Convenience is a real value and it is fine to choose it.

It matters much more if you are writing memoir involving people who have not consented, journalism with sources, anything under NDA, a diary, or a book whose commercial value depends on nobody seeing it before the auction. It also matters if you simply do not want the most personal file you own sitting readable on infrastructure you do not control — that is a sufficient reason on its own and does not require a threat model.

If you want to see what the trade buys in practice, CipherWrite is free to start — first book encrypted, on-device keys, exports included — and the architecture argument in full is at cipherwrite.com/why-encrypted. Our own longer write-up is the CipherWrite review, and for how it compares to Scrivener, Obsidian and the rest, see the best writing apps for authors. If you are specifically weighing a move off Scrivener, the Scrivener alternatives comparison is the narrower version of that question.

Whatever you land on, ask question one. The answer takes ninety seconds to find and it tells you almost everything.