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 If you had to highlight just one trust signal, which would it be?
If I had to choose one, it would be an independently reproducible build of the exact production APK. A demo can be staged, a permission screenshot can be outdated, and an audit can describe source code that is not identical to the binary people install.
A reproducible release connects the public source, build process and installed artifact through the same hash. It does not prove the code is vulnerability-free, but it lets other people verify permissions, cryptographic behavior and release changes against the actual binary. That makes the rest of the evidence materially harder to fake.
@daniil_katsura Do you think transparency alone is enough to win people over?
No. Transparency is necessary, but transparency alone can become well-written documentation that nobody can verify. It helps people understand what is claimed; it does not prove that the production binary behaves that way or that the workflow is reliable under failure.
Winning durable trust requires transparent limits plus repeatable evidence: reproducible artifacts, public test vectors, tamper and network-silence tests, stable signing-key governance, and eventually independent review. It also requires ordinary product reliability. People may try a security tool because it is transparent, but they keep it only if encryption and opening work consistently without creating new risks or friction.
@daniil_katsura Which part of the trust model has received the most criticism?
The plaintext lifecycle has received the most criticism, more than the choice of cipher. A keyboard is privileged software: it necessarily sees text while the user is composing, so the important questions are where that plaintext exists, whether it is ever committed to the chat field before encryption, whether it is persisted in history or temporary storage, and how buffers are cleared after a capsule is created.
The intended boundary is local composition followed by an explicit Encrypt action, with only the authenticated capsule committed in the protected workflow and no silent plaintext fallback. But a design claim is not enough. It needs release-specific instrumentation, crash tests, storage inspection and runtime verification across Android versions and messengers. No INTERNET permission reduces one risk; it does not by itself prove safe plaintext handling.
Public cryptograph specs are important, but for non technical users, an independent audit probably carries far more weight.
I agree. A public specification is essential for specialists and interoperability, but most people cannot evaluate a cryptographic format themselves. A credible independent audit is a much more understandable trust signal.
The word audited still needs precision: who performed it, what source and build were in scope, which version or APK hash was reviewed, what findings remained, and whether fixes were independently retested. Otherwise an audit badge can create more confidence than the evidence supports. The strongest combination is an audit tied to a reproducible production artifact, plus a plain-language summary of the limits. Until that exists, the product should say clearly that its current evidence is internal rather than borrow the authority of an external review.
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.
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.
I would appreciate a public cryptographic format with clear test vectors because developers and researchers can verify every step. Have you considered publishing a guide that lets anyone reproduce the entire encryption process independently.
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.
I would enable the keyboard only after seeing a two device demonstration details. Showing real attack scenarios and how the design resists them would make onboarding much stronger.
@stacey_connolly2 Agreed. The strongest onboarding demo should not be a happy-path video. I would structure it around repeatable failure cases: a modified capsule is rejected before plaintext is shown; the wrong password or recipient fails closed; a crash does not persist a draft; the messenger receives only the capsule in the protected workflow; and runtime capture shows no network traffic from the keyboard. Each result should be tied to the exact production APK hash and published test steps.
It should also state what the design cannot protect against: a compromised operating system, malicious accessibility service, screenshots, physical coercion, or an already-compromised recipient device. A two-device demo becomes credible when viewers can reproduce both the protections and the limits, rather than only watch the successful path.