What would make you trust an Android keyboard with encryption?
What would make you trust an Android keyboard that claims to encrypt your typing before it reaches the chat app? I’m testing a different UX: encryption at the keyboard layer, before plaintext reaches the chat app.
The difficult problem is not adding an Encrypt button. It is trust. A keyboard can see sensitive input, so enabling a third-party keyboard should require unusually strong evidence.
If you were evaluating this idea, which signal would matter first?
A. A two-device demo: type → encrypt → send → open offline
B. A clear permission screen showing that the APK has no INTERNET permission
C. A public cryptographic format with test vectors
D. Reproducible-build evidence
E. An independent audit before installation
What would you check first, and what would still stop you from enabling it?
The flow I’m testing is type → encrypt locally → send through Telegram → open offline on a second device. I’m looking for criticism of the trust model and onboarding, not support or upvotes.
Replies
@daniil_katsura What happens if the keyboard crashes while typing?
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.
@daniil_katsura What would stop someone from faking those trust signals?
That's the right challenge. Screenshots, badges, and even an unaudited repository can be faked. I do not think self-published trust signals are sufficient. The evidence needs to be independently reproducible: a versioned source tag, deterministic build instructions, an APK another party can rebuild to the same hash, transparent signing-key continuity, and ideally an independent review.
The goal should not be "trust us"; it should be making every claim cheap to falsify. A permission screen is useful context, but it is only one link in that chain.
I've learned that encryption is only part of the story. I'd first check reproducible builds, then verify there are no unnecessary permissions. My biggest concern would still be whether the keyboard ever stores plaintext locally, even temporarily.
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.
@daniil_katsura What if the app asked for one unexpected permission?
One unexpected permission would be a stop signal until it was explained and independently verified. For this product, INTERNET in a production build would directly contradict the core no-network claim. Broad storage, contacts, location, microphone, accessibility, or similar access should also be absent unless a specific optional feature genuinely requires it and the user deliberately enables it.
I would publish a permission manifest and a permission diff for every release. If an update adds anything new, the app should surface that change before installation rather than hide it in release notes. A permission can be legitimate, but an unexplained permission means the evidence chain has failed.
@daniil_katsura Would a video walkthrough increase your confidence?
@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.
@daniil_katsura How would you prove encryption is happening every single time?
I would avoid claiming that every keystroke is continuously encrypted. The safer and more honest model is an explicit secure-compose action: until the user presses Encrypt, it is a local draft; after that action, the app either produces an authenticated capsule or reports failure. It must never silently fall back to plaintext.
For proof, each release needs public test vectors, deterministic tests that decrypt the produced capsule independently, and negative tests showing that a modified capsule is rejected before plaintext is revealed. A visible state indicator helps the user understand what happened, but the real evidence is that another implementation can verify the exact output and that runtime tests confirm the messenger receives only the capsule in the encrypted workflow.
@daniil_katsura Would you keep using it after the first week?
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.
@daniil_katsura How would first time users know everything is working?
They should not have to infer it from a green shield. The first-run flow needs explicit, inspectable states: Draft (not encrypted or sent), Encrypted (an authenticated capsule was created locally and is ready to share), and Verified (the receiving app checked its authentication tag before revealing anything). If encryption fails, the state must say not encrypted and the workflow must stop - never fall back to plaintext.
For a first-use check, I would offer a short two-device offline test: create a capsule, share it by file or messenger, open it on the second device, then alter one character and show that opening is refused. The app can explain the state, but the durable proof comes from repeating that test with the production APK, inspecting its permissions, and publishing test vectors for the capsule format.
@daniil_katsura Would offline functionality be your biggest selling point?
Offline operation is an important proof point, but I would not make it the whole value proposition. The stronger point is that sensitive content can be encrypted before the chat application receives it. Working offline and having no network permission make that boundary easier to inspect and test.
Offline alone does not guarantee security: key handling, authenticated encryption, update integrity, plaintext cleanup and endpoint compromise still matter. I would present offline capability as a verifiable architectural constraint, not as a blanket claim that every risk disappears.
@daniil_katsura How long should someone need before they feel confident?
Confidence should be staged rather than tied to a single timer. A first-time user should understand the boundaries in a couple of minutes and be able to repeat a local or two-device test in about ten minutes. That can establish that the workflow behaves as described; it does not establish that the implementation is secure.
Deeper confidence should come from release-specific evidence over time: permissions, test vectors, tamper tests, signed hashes, reproducible builds and independent review. For an organisation, I would expect a scoped technical evaluation and pilot before real sensitive use. A security product should never pressure someone to trust it faster than the evidence supports.