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
Most answers here are attacking the evidence axis, so let me push on the other half of your question - what would still stop me enabling it.
I build a consumer product where people forward their actual phone calls to it (OsmO), so the ask is arguably more invasive than a keyboard. Two things surprised me running that gauntlet.
First: almost nobody verifies. Not "few" - close to zero. We published the evidence and watched the click-through. It is still worth publishing, because the handful who do check are the ones everyone else cites, so evidence works as social proof rather than personal proof. But it does not move installs. If you are tuning the A-E list to convert users, you are tuning the wrong surface.
Second: what actually moved adoption was blast radius and reversibility, not proof. Ordinary users never ask "is this secure." They ask "if you are wrong, what happens to me, and how fast can I undo it." Every point of adoption we gained came from shrinking the answer to that question, not from strengthening the crypto story.
Which leads to the thing that would stop me, and it is a trust-model criticism rather than a cryptographic one: you are asking for 100% of my typing, permanently, in order to secure the ~1% I actually want encrypted. Default keyboard is all-or-nothing and always-on. Even if every one of A-E checks out, the ask is badly matched to the value - I take total permanent exposure for an occasional benefit. "No INTERNET permission" answers "can they exfiltrate." It does not answer "why does this need to sit between me and my banking chat, my work Slack and my password fields in order to encrypt one message to my co-founder."
The version I would enable is the one where the secure surface is not my everyday keyboard - invoked deliberately for the message I am protecting, dormant otherwise. Then exposure matches benefit, and the evidence you publish is defending a much smaller claim, which makes it far easier to believe.
Genuinely unsure on one point though: is always-on default a deliberate bet on the encryption needing to be zero-friction at the moment of typing, or is it a constraint of what Android lets an IME do?
You are worried about the right thing, and since you asked for criticism rather than support, the useful push is on which signal you rank first. The one that matters is not the signal that shows good behavior, it is the signal that removes the ability to misbehave. By that test B beats A. A two device offline demo proves it can work without a network, but not that it will stay off one the moment a network is there. No INTERNET permission is enforced by the platform, not promised by you, so it is the strongest single item on your list. Pair it with D so I can confirm the build I install is the one that was audited, since a permission screen only means something for a binary I can verify.
The honest reason none of these fully close it: a keyboard with no network can still write to local storage, and a companion app that does have network can ship it later. So the trust boundary is not the keyboard alone, it is the keyboard plus everything that can read what it stores. If onboarding names that out loud and shows how you contain it, the security minded people you most want will relax. If it stays quiet on that, they will assume the gap is there, because it usually is.