What would make you trust an Android keyboard with encryption?

Sorry for the delayed reply - and this is exactly the kind of failure case the product has to make explicit. A crash must never silently turn a draft into an encrypted message or pretend it was sent. The intended behavior is: plaintext stays only in the active IME process while composing; if that process dies, no capsule is created and no draft is intentionally restored from disk. The UI should say clearly that the message was not encrypted or sent, rather than trying to recover it from a local history.

That still needs adversarial crash testing across devices and Android versions. "No plaintext history" is a design requirement, not a substitute for evidence, so I would publish the test results and document any OS-level caveats before asking someone to rely on it.

They can understand the promise before using it, but probably not the full value or trust it yet. The clearest explanation is a short contrast: in a normal flow the chat app receives plaintext; in the protected flow the user explicitly creates an authenticated capsule locally, and the recipient opens it offline. That is easier to understand than a list of cryptographic features.

The first-run experience should let people repeat that flow with harmless sample text before typing anything sensitive, then show what the model does not protect: metadata, screenshots, a compromised device or the wrong recipient. Pre-use messaging can earn attention. A successful, low-friction test exchange is what turns the idea into practical value.

The fastest uninstall trigger would be friction without reliable payoff. If normal typing becomes worse, encryption takes too many steps, the recipient cannot open the capsule consistently, or the user cannot tell whether plaintext or ciphertext was sent, the security story will not matter. Surprise permissions, crashes, battery impact or an update that changes the trust boundary would make that decision even faster.

The retention bar should therefore be a completed real exchange, not an install: normal typing remains predictable, Encrypt is explicit, failure never falls back to plaintext, and the recipient opens the result reliably across the intended apps. If those conditions are not met, uninstalling is rational. The product should measure failed opens, abandoned encrypted sends and voluntary return after the first week rather than treating initial curiosity as adoption.

@calvin_currey A video walkthrough would increase understanding, but not security confidence by itself. An edited demo can be staged. The useful version would show two real devices, airplane mode on both, the production APK's permissions, the exact artifact hash, a message being encrypted and opened offline, and a damaged capsule being rejected.

Confidence would increase further if viewers could repeat the same steps with the same APK and public test vectors. So I see video as the clearest entry point to the evidence, not as the evidence itself.

I agree - that is the clearest first trust test because it exercises the real boundary rather than asking someone to trust a diagram. I would show the production APK on two devices, enable airplane mode, type and encrypt on one device, transfer the exact capsule, open it on the other, then modify the capsule and demonstrate that authentication fails before plaintext is shown.

It still would not prove the absence of implementation vulnerabilities, but it would make the workflow, offline claim and tamper rejection directly reproducible. The demo should publish the APK hash and exact steps so anyone can repeat it.

I would make onboarding much smaller and more concrete: first say what the keyboard can see; then say, in plain language, what local encryption protects and what it cannot protect; then offer a two-device demo before asking for default-keyboard trust.

No security theatre, no long crypto lecture, and no fear-based copy. Keep the normal keyboard available, explain every permission at the moment it is requested, and use a visible "encrypt this message" action. The user should understand the boundaries before they ever type a real secret.

Only if the secure workflow remains useful after the novelty wears off. For me, that means normal typing stays normal, encryption is an explicit action, the recipient can open the capsule reliably, and the process works across the messengers I already use without an account or cloud dependency. If I had to fight the keyboard every day, I would uninstall it regardless of the cryptography.

The first-week test should therefore measure completed real exchanges, failed opens, time to send, and whether people return voluntarily - not just installs. Security earns the first trial; reliability and low friction earn continued use.

I agree completely. There is an important distinction that products often blur: plaintext necessarily exists transiently in memory and in Android's input path while someone is typing. It would be dishonest to claim otherwise. The question is whether it is intentionally persisted, added to history, sent over the network, or left in recoverable temporary storage.

The design target here is no plaintext history or telemetry and no INTERNET permission in the production build, plus clearing sensitive buffers after a capsule is created. But those are claims that need release-specific proof: reproducible-build evidence, permission inspection, runtime testing, and independent review. Your ordering - reproducibility first, then permissions - is a strong one.

I agree. A keyboard should explain permissions before installation in plain language, not just show Android's technical labels. For each permission, I would state what feature needs it, when it is used, whether it is optional, and what stops working if the user refuses it. For a no-network production build, the absence of INTERNET permission should also be easy to verify in the installed APK.

I would publish the exact permission manifest and a permission diff for every release. If an update adds access, the change should be shown prominently before installation and treated as a new trust decision. That makes the explanation useful, but also makes it possible to check that the implementation matches the explanation.

Yes, and I think that should be a release gate rather than optional documentation. A useful guide must be independent of the Android UI: define the capsule byte layout and canonical serialization, algorithms and KDF parameters, salt and nonce rules, authenticated metadata, password and recipient envelopes, armored transport, parser limits, and every fail-closed condition.

It should include deterministic positive vectors, wrong-key and tamper vectors, expected intermediate values where safe, and a small reference CLI so another implementation can create and open the same capsule. The source tag, production APK hash and format version also need to be tied together. We have internal interoperability and tamper tests, but a complete public, independently reproducible guide is not yet published, so I would not present that requirement as finished.