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 Would people understand the value before using 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.
@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 make someone uninstall it after trying?
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.
@daniil_katsura Friction!!
I choose this
A. A two-device demo: type → encrypt → send → open offline
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.
@daniil_katsura What would make the onboarding feel less intimidating?
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.
I would want a simple explanation of every permission and why each one exists. That would reduce hesitation before installing.
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.
The trust model is strong on paper because it removes capability rather than adding promises. No INTERNET permission is the one signal a screenshot cannot fake. The weakness is onboarding. Every proof you listed, reproducible builds, test vectors, permission diffs, is checkable by maybe one install in a thousand. Everyone else falls back to the green shield you are right to distrust. So you have built an evidence chain for auditors and a leap of faith for users, and the two audiences never meet.
I would design onboarding around that gap directly. Do not ask the ordinary user to verify anything. Make verification a visible act that a few competent people perform in public and everyone else inherits. Surface, inside the app, the count of independent rebuilds that matched the published hash for this exact version, linked to who did them. That turns a claim only experts can check into a signal a normal user can read, without pretending they audited it themselves. The failure mode to watch is the first release where nobody reproduces the build in time, because then the shield quietly goes back to meaning trust us.
B first, because it is the only signal on your list I can verify myself in under a minute, and it cheaply rules out the worst outcomes. A is the most persuasive to watch but it proves the demo, not the shipped artifact, so A without D is theatre. What would still stop me is updates. The realistic threat is not version one, it is a later version quietly widening its access once trust is established, so permission diffs surfaced before install plus reproducible builds are the pair that matters, and you need evidence the store artifact matches the audited source, not just that a clean build exists. The other honest blocker is recipient friction. If my contact needs the same tool to read anything I send, convenience beats security for most people within a week. Being explicit about who this is for, high sensitivity use rather than everyday chat, would do more for trust than another badge.
the two-device offline test proves the crypto works, but what about the first key exchange itself - how does device two get the key the very first time, is that pairing step also offline/out-of-band, or does it become the one step people don't think to scrutinize?