A hardened in-app keyboard, so keystrokes stay local.

You can encrypt a message end-to-end and still leak it — because the keyboard you typed it on is a separate app, made by someone else, that may send what you type to its own cloud. It is the most overlooked gap in mobile privacy: the layer between your fingers and your encrypted app. Helix gives you a keyboard built into the app itself, so what you type there never passes through a third-party keyboard. Here's how cloud keyboards work, why they are an exfiltration vector, and the honest limit of what an in-app keyboard can protect.

1. What an in-app keyboard is

On a phone, the keyboard you see when you tap a text field is usually not part of the app you are using. It is a separate program — an input method editor, or IME — that the operating system summons to handle typing on behalf of every app. Gboard, SwiftKey, and the default keyboards from your phone's maker are all IMEs. When you type a message, a password or a note in any app, your keystrokes pass through that keyboard before they reach the app. The keyboard is a layer that sits between your fingers and everything you type.

An in-app keyboard is a keyboard that the app provides itself, rendered and handled inside the app's own boundary, so that what you type into that app does not pass through a separate, third-party keyboard at all. Your keystrokes go from your fingers to the app directly, without a detour through an IME made by another company. For most apps this would be overkill. For an app whose entire purpose is protecting what you type, it closes a gap that end-to-end encryption alone cannot.

2. How third-party cloud keyboards work

To see why this matters, look at what a modern keyboard actually does. The popular third-party keyboards are not simple key grids. They offer autocorrect, predictive text, swipe typing, learned personal dictionaries, multilingual suggestions and more. To deliver those features well, they observe what you type and adapt to it — and some of that adaptation happens, or can happen, in the cloud.

This is where the privacy question lives. Many feature-rich keyboards have options that send data off the device: typed text or fragments used to improve predictions, your personal dictionary synced across devices, usage analytics, and "personalization" that learns your style server-side. Some of these are on by default; some are opt-in; the exact behavior varies by keyboard, by version and by setting. The point is not that every keyboard is malicious — it is that a third-party keyboard is an app with broad visibility into everything you type and, frequently, a network connection and a business reason to use it. You are trusting that vendor, their settings, and their security with the raw stream of your keystrokes.

Even setting cloud features aside, a third-party keyboard runs with a privileged view: it can see the text in fields across your apps. On mobile platforms, keyboards have to request special permission precisely because of how much they can observe. Granting "full access" to a keyboard is granting a third party a window onto your typing. Most people tap "allow" without registering what they have agreed to.

3. The gap: encrypted app, leaky keyboard

Here is the gap that an in-app keyboard closes, and it is genuinely counterintuitive. Suppose you use a perfectly secure, end-to-end encrypted messenger. The message is encrypted on your device and only the recipient can read it. The encryption is flawless. And yet — before the message was ever encrypted, you typed it, character by character, through a third-party keyboard. If that keyboard observed the text and sent any of it to its own servers, your "end-to-end encrypted" message already left a copy somewhere, in plaintext, before encryption ever happened.

Encryption protects data in transit and at rest. It cannot protect data at the moment of creation, when it is still plaintext under your fingers. The keyboard sits at exactly that moment — upstream of every encryption your app applies. This is why a secure app with an insecure input layer is only as private as that input layer. The strongest cipher in the world is irrelevant if the words were copied before they were encrypted.

End-to-end encryption protects the message after you type it. The keyboard sees it while you are typing it. A third-party cloud keyboard is upstream of every protection your app provides — which is why the input layer is its own problem.

An in-app keyboard removes that detour. When you type inside Helix on its own keyboard, the keystrokes never pass through Gboard, SwiftKey or any other third-party IME. There is no separate keyboard observing the text, and therefore no third-party keyboard that could relay it to a cloud. What you type goes from your fingers into the app, and the app's encryption applies to text that no other program ever saw.

It is worth being precise about why this is structural rather than a matter of trust. With a third-party keyboard in the loop, your security depends on a chain of assumptions: that the keyboard's cloud features are configured the way you think, that the vendor's privacy promises hold, that their servers are not breached, that an update did not quietly change a default, and that the keyboard itself was not malicious to begin with. Each link is a thing you cannot inspect and do not control. An in-app keyboard does not ask you to verify any of that, because it removes the link entirely. There is no external keyboard whose behavior you have to trust, because there is no external keyboard in the path. Eliminating a dependency is stronger than auditing it.

4. The threat it stops: keystroke exfiltration

The threat is the quiet exfiltration of your keystrokes by the keyboard layer — and the related risk of a compromised or malicious keyboard. Concretely:

• Cloud-keyboard data collection. A keyboard with cloud features may transmit typed text, fragments, learned phrases or analytics to its vendor's servers. Even when well-intentioned, this places a copy of what you typed somewhere off your device, subject to that vendor's retention, breaches and legal demands. For ordinary text it is a privacy cost; for a password or a recovery phrase it is a serious leak.
• The privileged keyboard surface. Because a keyboard can see text across apps, a malicious or compromised keyboard is effectively a keylogger you installed and granted permission to. There is a real history of dubious third-party keyboards on app stores, and of security findings about how much keyboards transmit.
• Sensitive fields you didn't think about. The keyboard sees not just messages but passwords, card numbers, seed phrases and search queries — everything you type, everywhere. A single broadly trusted keyboard is a single broadly placed observer.

An in-app keyboard removes the third-party keyboard from the path for the text you type inside the protected app. There is no separate IME to collect it, sync it, or relay it — and nothing for a malicious keyboard to observe in that context, because no external keyboard is involved.

5. Why this is the weak link people miss

People reason carefully about encryption and almost never about the keyboard. They will compare ciphers, scrutinize a messenger's protocol, and debate forward secrecy — and then type the whole conversation through a free cloud keyboard they installed years ago and never thought about again. The keyboard is invisible precisely because it is everywhere; it fades into the furniture of the phone.

That invisibility is what makes it the weak link. An attacker or a data-hungry vendor does not need to break your encryption if they can read the text before it is encrypted. The keyboard is the cheapest, broadest place to do that, because one keyboard sees everything you type in every app. Hardening the input layer for the app that matters most is not paranoia — it is closing the obvious gap that all the careful work on encryption otherwise leaves wide open. It is the difference between locking the vault and also caring about who was in the room while you wrote the combination.

There is a second reason this gap persists: the keyboard's data collection is framed as a feature, not a leak. Predictive text that learns your style, a personal dictionary that follows you between devices, suggestions tuned to how you write — these are sold as conveniences, and they are. But every one of them implies that the keyboard is observing and, in many configurations, retaining or transmitting what you type. The privacy cost is bundled into a feature you were told to want, which is precisely why people accept it without noticing. The pattern is familiar from the rest of the modern phone: the most invasive behavior is the one dressed up as the most helpful.

The result is a strange asymmetry. We have collectively decided that the contents of a message deserve serious cryptography, and we are right. But the act of composing that message — the moment the words first exist — we hand to whichever keyboard was easiest to install, governed by settings most people have never opened, run by a company whose incentives may not be ours. The in-app keyboard exists to correct that asymmetry for the typing that matters, putting the same care into how the words are entered as into how they are protected once entered.

6. Who needs a hardened keyboard

Anyone who types secrets benefits, and a few groups should treat the keyboard layer as a first-order concern:

• Crypto holders. A seed phrase or private key typed through a cloud keyboard may be the most valuable string of characters that keyboard ever sees. Keeping that entry on an in-app keyboard — alongside a self-custody wallet and on-device notes — keeps the most dangerous keystrokes off any third party.
• Journalists and their sources. The content of a sensitive message is exactly what must not leak before encryption. A source's name typed through a cloud keyboard can defeat an otherwise airtight channel.
• Executives and lawyers. Privileged and confidential text composed inside a secure app should not detour through a third-party keyboard's cloud on its way to being encrypted.
• The specifically targeted. If someone is willing to compromise your device or your apps, the keyboard is an obvious and broad target. Removing it from the path for your most sensitive typing shrinks what they can reach.
• Anyone who installed a third-party keyboard and forgot. If you granted "full access" to a keyboard years ago, an in-app keyboard quietly takes the most sensitive typing back out of its view.

7. How Helix does it

Helix ships its own keyboard, rendered inside the app, and uses it for sensitive entry so that what you type within Helix does not pass through Gboard, SwiftKey or any other third-party IME. Your keystrokes are handled inside the app's boundary and never handed to an external keyboard that could observe or transmit them. The text you compose is then protected by Helix's encryption — applied to characters that no separate keyboard program ever saw.

This is the input-layer companion to the rest of the suite. Helix already keeps your messages off third-party servers, your notes on-device, and your secrets in the vault; the in-app keyboard extends that discipline upstream, to the moment of typing itself. It is also a natural partner to the device-level shield: the keyboard closes the third-party-IME path, and the shield watches for the deeper compromise that would undermine any keyboard. Together they reflect the honest position that securing what you type means caring about the input layer, not just the cipher.

The design also keeps the keyboard deliberately plain, and that plainness is itself a privacy choice. Much of what makes third-party keyboards leaky is the very machinery that makes them feel smart — the cloud-backed prediction, the cross-device learning, the personalization that has to phone home to work. An in-app keyboard built for sensitive entry does not need to be a learning, syncing, suggesting product; it needs to take your keystrokes and hand them to the app, and nothing more. By not reaching for the features that create the exfiltration surface in the first place, it has far less to leak. The absence of cleverness is the point: a keyboard that does not learn you cannot send what it learned.

8. The honest limits

An in-app keyboard closes a real and widely ignored gap, and its scope is specific. We will be plain about it:

• It covers in-app entry, not OS-wide typing. This is the central limit. The hardened keyboard protects what you type inside Helix. It does not replace your system keyboard everywhere else. When you type into your email app, your browser or any other app, you are still using whatever keyboard your device is set to — including a third-party cloud keyboard if that is what you have chosen. The protection follows the app, not the whole operating system.
• It is not a defense against a fully compromised device. If spyware has taken the device at a deep level, it can potentially observe input regardless of which keyboard renders it, because it sits below the app entirely. Removing the third-party IME closes the keyboard-as-collector path; it does not defeat a kernel-level implant. That deeper threat is the device shield's domain, and detection there is a strong signal rather than a guarantee.
• Your own habits still matter. An in-app keyboard cannot help with text you choose to type elsewhere, paste from another app, or dictate by voice through a third-party service. The protection is for keystrokes entered on Helix's keyboard, within Helix.
• It is about the path, not magic. The benefit is structural and modest in mechanism: by not routing your typing through a separate third-party keyboard, there is simply no external IME in the loop to collect it. That is the whole claim — no more, and no less.

Within that honest scope, the value is clear: for the typing that matters most, the keyboard stops being a third party with a view of your keystrokes, and what you type reaches Helix's encryption having passed through nothing but your own app.

$199/month Core · $499/month Operator · $999/month Sovereign — or 30% off paid annually.