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 kind of feedback have security people given you?
The most consistent security-focused feedback has been that no network permission is useful but not sufficient. A keyboard is highly privileged, so reviewers want explicit plaintext handling, authenticated encryption with tamper rejection, careful key exchange, stable signing-key governance, reproducible-build evidence, permission diffs and runtime network testing for the exact release.
Another repeated point is to state the limits plainly: this does not hide metadata, prevent screenshots, repair a compromised device or protect against choosing the wrong recipient. We have internal tests and community threat-model criticism, but not an independent audit, so I would not present the current evidence as external validation.
@daniil_katsura How would updates affect that trust over time?
Updates are part of the threat model, not a maintenance detail. A trustworthy update path needs stable release-key governance, a versioned changelog, signed artifact hashes, an SBOM and permission diff, and regression tests for the encryption and no-network claims. A material change to permissions or the crypto format should be prominent, not buried in release notes.
I would not ask someone to accept automatic trust indefinitely. Each release should be independently verifiable, and high-trust users or organisations should be able to hold a known version while they review a change.
@daniil_katsura Would you feel comfortable making it your default keyboard?
Personally, no - not before the evidence is strong enough. Making a keyboard the default grants it visibility into far more than the one message a person intends to protect, so the bar should be higher than for a normal app.
The safer adoption path is an explicit secure-compose action while the user's usual keyboard remains the default. I would only consider default-keyboard use after reproducible releases, broad device testing, a clear data-lifecycle explanation, and an independent security review. Convenience is not a reason to lower that bar.
@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.
@daniil_katsura Would you trust it more if someone you knew recommended it?
A recommendation from someone I know would make me more willing to try a product, but it should not change the security decision. Referrals are social proof, not cryptographic proof.
The strongest version is both: a recommendation from a person who has actually tested the workflow, plus independently verifiable artifacts for the exact release being installed. If the evidence is not strong enough for a stranger to check, it is not strong enough to outsource to a friend's trust.
@daniil_katsura Could someone test the encryption without another device?
Yes, a useful single-device self-test is possible. Someone can create a capsule, open a saved local copy, then alter the encoded data and verify that authentication fails. They can also repeat the test in airplane mode and inspect the installed app permissions.
What one device cannot prove well is the full sender-to-recipient path, interoperability between independent installations, or whether key exchange is understandable in practice. A second device therefore remains the stronger acceptance test. The single-device test is good for learning and basic tamper verification, but it should not be presented as complete security proof.
@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 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 How do you stop people from assuming it's just another keyboard?
The distinction has to be visible in the first interaction, not explained in a long feature list. The core demonstration should show ordinary text becoming an authenticated encrypted capsule before it enters the chat application, then opening offline elsewhere and refusing a modified capsule.
I would avoid positioning it as a better general-purpose typing experience. Normal typing should remain predictable; encryption should be an explicit action with clear Draft, Encrypted and Verified states. The category is a confidentiality layer that works across existing communication tools. The keyboard is one interface to that layer, not the entire product identity.
@daniil_katsura What's been the toughest objection you've heard so far?
The toughest objection is that a privacy keyboard asks the user to trust software that can potentially see everything they type. That is a valid objection, and marketing cannot remove it. Even without INTERNET permission, a malicious update, unsafe local storage, clipboard leakage, weak key handling or a compromised device would still matter.
The response has to be reducing and verifying the trust surface: keep encryption explicit, persist no plaintext history, fail closed, publish release-specific permissions and hashes, support reproducible builds, run runtime tests, and obtain independent review. Until that external review exists, the honest answer is that users should treat the current evidence as internal, not conclusive.