Phone Keyboard Privacy: What Keyboards See and How to Lock Them Down

A phone keyboard sees almost everything you type into it, because typing is its job. On Android, the active input method receives your keystrokes in every field, password fields included, and can read text around the cursor. On iPhone, a third party keyboard is sandboxed with no network access until you turn on "Allow Full Access", and iOS swaps in the system keyboard for password and phone number fields.

What happens next depends on the keyboard. A keyboard that works entirely on the device keeps your words on the device. A keyboard with cloud features (voice typing, search, cloud prediction, synced dictionaries) sends some of what you type or say to a server, and independent research has shown that some of those connections were badly protected. To lock a keyboard down, remove the ones you do not use, deny Full Access unless a feature truly needs it, turn off the cloud features you do not want, clear learned words, and, on work phones, let your IT team allowlist keyboards.

Key takeaways

• The keyboard sits between your fingers and every app. Android's own setup warning says an input method "may be able to collect all the text you type".
• iOS and Android draw the line differently. iOS sandboxes keyboards with no network and swaps in the system keyboard for secure and phone pad fields. Android has no swap: your chosen keyboard types your passwords too.
• "Allow Full Access" is the iOS network switch. Without it, Apple says keystrokes cannot be sent anywhere. With it, they can go to the developer's servers.
• Android's "do not learn" flag is a request. Google's reference says some input methods may not respect IME_FLAG_NO_PERSONALIZED_LEARNING.
• Cloud features are where text leaves the phone. Search, voice, cloud prediction and sync all send something to a server.
• Research found real leaks. Citizen Lab's April 2024 report found exploitable flaws in cloud pinyin keyboards from eight of nine vendors. Most were fixed; as of 1 April 2024 two products still had working exploits.
• Enterprises can allowlist keyboards on Android. On iOS, Apple's MDM schema controls keyboard features, and apps can refuse custom keyboards themselves.

What a keyboard can see on Android

On Android, a keyboard is an input method editor (IME). It is an app that contains a service built on InputMethodService. Google's guide to creating an input method shows the service declared with the android.permission.BIND_INPUT_METHOD permission and an intent filter for android.view.InputMethod. That permission means only the system can bind to the service: an ordinary app cannot pretend to be the input framework and connect to it.

Once you enable the IME and pick it, the system routes input from every text field in every app to it. Two objects define what it gets.

EditorInfo: what kind of field this is

When you tap into a field, the system calls the keyboard's onStartInput with an EditorInfo object. The InputMethodService reference explains that the keyboard can read EditorInfo.inputType to "detect password mode, auto complete text views, phone number entry". So the keyboard knows that a field is a password field. It is told, not blocked.

EditorInfo also carries imeOptions, flags the app sets to ask the keyboard for certain behaviour. The privacy relevant one is covered in its own section below.

InputConnection: the text around the cursor

The keyboard talks to the app through an InputConnection. Google's InputConnection reference lists methods such as getTextBeforeCursor, getTextAfterCursor, getSelectedText and getExtractedText, which retrieves "the current text in the input connection's editor" and can monitor it for changes. A keyboard needs this to autocorrect, capitalise and suggest the next word. It also means a keyboard can read more than the letters you type in the moment: it can read text already in the field.

The clipboard

Since Android 10, Google's privacy changes page says that unless an app is "the default input method editor (IME)" or the app in focus, it cannot read clipboard data. Background apps lost access; the active keyboard kept it. Android 13 lets apps mark copied secrets with ClipDescription.EXTRA_IS_SENSITIVE, which hides them in the copy preview but not from the keyboard.

Password fields on Android

This is where Android and iOS differ most. Google's input method guide describes TYPE_TEXT_VARIATION_PASSWORD as a variant for entering passwords, and then gives keyboard developers an instruction rather than a system guarantee: hide the password in the input and candidate views, and "Don't store passwords on a device". Nothing in Google's documentation describes the system swapping your chosen keyboard out for a system keyboard when a password field gets focus. Your chosen keyboard types your passwords, and the protection is that the keyboard behaves well.

That is why Android shows a warning when you enable a new keyboard. Citizen Lab's report quotes it: "This input method may be able to collect all the text you type, including personal data like passwords and credit card numbers." The warning appears for every keyboard, whether it ever talks to the network or not.

What a keyboard can see on iPhone

On iOS, a third party keyboard is a custom keyboard app extension. Apple's documentation describes it as an extension that "replaces the system keyboard", and its job is to insert text at the cursor through the textDocumentProxy object. The keyboard can insert and delete text and can read the context before the cursor through documentContextBeforeInput, which it needs for deletion by word and for suggestions.

Apple's App Extension Programming Guide also lists what a custom keyboard does not get:

• It cannot select text. Selection belongs to the host app, and the keyboard has no access to the host app's Cut, Copy and Paste editing menu.
• It does not get the system keyboard settings in Settings, such as Auto Capitalization, or the system's Reset Keyboard Dictionary feature. Keyboards that want settings ship their own settings bundle.
• It gets a basic lexicon through UILexicon, which Apple says includes unpaired first and last names from the user's contacts, the user's text replacement shortcuts and a common words dictionary. That lexicon is available whether or not the keyboard has Full Access.

Why iOS swaps in the system keyboard for secure fields

Apple's guide states that a custom keyboard is "not eligible" to type into a secure text input object, a field whose secureTextEntry property is set and which shows dots as you type. When you tap one, "the system temporarily replaces your custom keyboard with the system keyboard", and your custom keyboard comes back when you move to a normal field. The same happens for phone pad fields that use UIKeyboardTypePhonePad or UIKeyboardTypeNamePhonePad, such as phone number fields in Contacts.

The reasoning is plain: a password typed into a field that the app has marked secure never passes through the third party keyboard. The catch is the word "marked". If an app collects a password, a one time code or a card number in a field it has not marked secure, the custom keyboard types it like any other text. That gap is one of the common mistakes later in this post.

Apps can refuse custom keyboards completely

Apple gives app developers one more switch. An app can implement application(_:shouldAllowExtensionPointIdentifier:) in its app delegate and return false for the keyboard extension point. Apple's guide gives the examples of a banking app or an app that must conform to the US HIPAA privacy rule. In that app, users always get the system keyboard. Apple's reference for the method notes that in iOS 8.0 the custom keyboard was the only extension type an app could reject this way.

What "Allow Full Access" unlocks on iOS

Every custom keyboard starts in a tight sandbox. Apple's current documentation, "Configuring open access for a custom keyboard", says the default configuration "disallows access to the network" and prevents writing to the containing app's shared group containers, though reading is allowed. Apple also lists no access to the microphone and speaker, and no part in iCloud, Game Center or In-App Purchase.

A developer who wants more sets RequestsOpenAccess to true in the keyboard's Info.plist. That only asks. The user still has to turn on the "Allow Full Access" switch for that keyboard in Settings. Inside the keyboard, the developer can check the hasFullAccess property of UIInputViewController to see whether the user agreed.

With Full Access on, Apple's documentation lists these extra capabilities:

The older App Extension Programming Guide adds the pasteboard (UIPasteboard) and audio playback such as key clicks to the list. Apple frames the trade in one line: without Full Access, "users know that keystrokes go only to the app" using the keyboard; with it, "they know their keystrokes are available to the keyboard developer". Apple's guide also says that without open access "the system ensures that keystrokes cannot be sent back to you or anywhere else".

What Apple requires of keyboard developers

Apple's App Review Guidelines give keyboards their own rule, 4.4.1. Keyboard extensions must provide keyboard input, follow the sticker guidelines if they include images or emoji, provide a way to move to the next keyboard, "remain functional without full network access and without requiring full access", and "collect user activity only to enhance the functionality of the user's keyboard extension on the iOS device". They must not launch apps other than Settings or repurpose keyboard buttons for other behaviours.

Two other rules touch keyboards. Guideline 2.5.18 says display advertising should not be included in extensions, and keyboards are named in the list. Guideline 5.2.5 says third party keyboards may not include Apple emoji.

Apple's developer guide adds data duties for open access keyboards, including not storing received keystroke or voice data except to provide services that are obvious to the user.

For users, the practical reading is simple: under Apple's rules a keyboard has to work with Full Access off. If one refuses basic typing until you turn it on, question it.

Android's privacy controls, and whether keyboards honour them

Android does not have a Full Access switch for keyboards. Any app, including a keyboard, gets ordinary network access through the normal internet permission that apps declare. The controls that exist live in three places: flags that apps send to the keyboard, the keyboard's own settings, and policy set by an employer.

IME_FLAG_NO_PERSONALIZED_LEARNING

Since API level 26 (Android 8.0), apps can set IME_FLAG_NO_PERSONALIZED_LEARNING in a field's imeOptions. Google's EditorInfo reference says it asks the keyboard not to update "any personalized data such as typing history and personalized language model" from that field. The reference gives two use cases: an app in a mode where activity should not be recorded, noting that "some web browsers and chat applications may have this kind of modes", and fields where storing history makes no sense, such as typing games or promotion codes.

Then comes the sentence that matters: "the flag is not a guarantee, and some IMEs may not respect it." Android does not enforce the flag. Whether it works depends on the keyboard you installed. The flag also says nothing about the network. It asks the keyboard not to learn from the field; it does not stop a cloud feature from processing what you type there.

Password and input type hints

TYPE_TEXT_VARIATION_PASSWORD and the related password variations tell the keyboard what the field is. Google's guide tells keyboard developers to hide passwords in their UI and not to store them. A well built keyboard turns off suggestions, learning and cloud prediction in those fields. As with the learning flag, this is the keyboard's behaviour, not a system wall.

The keyboard's own settings

On Google's own keyboard, Gboard, the help centre documents three settings that matter for privacy:

• Saved words. Google's Gboard troubleshooting page says Gboard saves the words you type "to help you with spelling" and that "these words are saved only to your device". You can delete them from the keyboard's Settings, then Dictionary, then Delete learned words, confirming with a number the keyboard shows you.
• Personalisation and learning data. Gboard's privacy settings (Settings, System, Language and input, On-screen keyboard, Gboard, Privacy) include "Personalize for you", which saves audio recordings and transcripts on the device, and "Delete learned words and data", which "clears all on-device data that Gboard has saved".
• Improve for everyone. This is the federated learning switch, covered below. Google says it is on by default and can be turned off.

Do keyboards honour these controls?

You cannot test this from your phone, and Google's documentation says the flag may be ignored. Trust a keyboard as much as you would trust an app that could read every message you write, because that is the access it has.

What cloud keyboard features send

Cloud features are the point where text leaves the phone. The details vary by keyboard, so this section sticks to what Apple and Google document for their own keyboards and then describes the categories.

Google's keyboard

Gboard's troubleshooting page has a short list titled "What Gboard sends to Google":

• Your searches, so Google can return search results.
• Usage statistics, to show which features are used most.
• Your voice, if you use the talk-to-text feature, "for transcription".

Under "What Gboard doesn't send to Google", the page lists "anything you type, other than your searches, like passwords or chats with friends", and says saved words are not sent.

Voice is more nuanced than that list suggests on newer phones. Google's page on advanced voice typing features says that when the colourful microphone icon shows, "the text you speak stays on your device and isn't sent to Google servers except when you use the 'Fix it' or detailed edits features". For detailed edits, Google says your voice command transcript and the full text from the input field are sent to Google servers, no audio is sent, and no text or audio is stored on Google servers. The same page says detailed edits are available on Pixel 9 (excluding 9a) and later.

Google also documents optional audio snippet donation: snippets of up to 15 seconds are stored by Google for up to 18 months, unlinked from your account, and "human reviewers may listen to or transcribe some snippets".

Apple's keyboard and dictation

Apple's iPhone User Guide says dictation "is processed on your iPhone in many languages, and no internet connection is required". It adds an important exception: when you dictate in a search field, "your dictated text may be sent to the search engine to process the search".

Apple's Siri, Dictation and Privacy notice explains how to tell which mode you are in: "your device will indicate in Keyboard Settings if your audio and transcripts are processed on your device and not sent to Apple servers. Otherwise, the things you dictate are sent to and processed on the server, but will not be stored unless you opt in to Improve Siri and Dictation."

Apple's system keyboard dictionary is local too. The iPhone User Guide says you add words to the keyboard dictionary by rejecting words iPhone suggests, and that Reset Keyboard Dictionary "erases only the words you've added".

The categories, for every other keyboard

On iOS, every row needs Full Access for a third party keyboard. On Android, any keyboard can do all of it.

How federated learning works in a keyboard

Federated learning is how a keyboard can learn from what millions of people type without collecting the text. Google introduced the approach in a research blog post on 6 April 2017, describing a test in Gboard on Android: when Gboard showed a suggested query, the phone stored the context and whether you tapped it locally, and federated learning processed that history on the device to improve the next suggestion model.

The keyboard paper is "Federated Learning for Mobile Keyboard Prediction" by Andrew Hard and colleagues at Google, posted to arXiv on 8 November 2018. Its main points:

• The model is a small recurrent network (a coupled input and forget gate variant of an LSTM) with about 1.4 million parameters, sized for phones.
• Training data stays in a cache on each device. Devices take part only if they have at least 2 GB of memory available and are "charging, connected to an un-metered network, and idle". The paper notes these criteria were chosen for Gboard and are not inherent to federated learning.
• Each device trains on its own text and sends a model update, not the text. The server averages the updates (Federated Averaging) into a new shared model.
• The federated model converged after 3,000 training rounds, in which 600 million sentences were processed by 1.5 million clients over about four to five days, and it achieved better prediction recall than the server trained comparison.
• Chat apps made up 66 percent of the sampled client cache data, which is why keeping that text on the device matters.

Google's current Gboard help page describes the same idea in plain words: federated learning "doesn't send the text you speak or type to Google, but will send what it learns to Google", runs only while the phone charges, is on Wi-Fi and is not in use, and is on by default with a switch to turn it off.

Two limits matter. A model update is not nothing, which is why Google's 2017 post described Secure Aggregation, under which the server can only decrypt the average update once "100s or 1000s of users have participated". And federated learning covers training only, not search, voice or cloud prediction traffic. Our explainer on how federated learning works and what it does not protect goes deeper on both.

What independent research found about keyboards on the network

The strongest public evidence comes from the Citizen Lab at the University of Toronto, which tested apps, disclosed flaws to vendors and published after the fix windows.

The 2023 study: one widely used cloud pinyin keyboard

Citizen Lab's Report No. 170 of 9 August 2023 examined a Chinese input method that the report says had over 450 million monthly active users. Its custom encryption, used instead of TLS, let a network eavesdropper on the Windows and Android versions recover what users typed.

Was it fixed? Yes. The report says fixed versions were released by 20 July 2023, and the 2024 report confirms the developer moved those transmissions to TLS.

The 2024 study: nine vendors, eight with exploitable flaws

Citizen Lab's follow up, "The not-so-silent type", Report No. 175 by Jeffrey Knockel, Mona Wang and Zoë Reichert, was published on 23 April 2024. The researchers tested cloud based pinyin keyboards from nine vendors: three keyboard developers and six phone makers that either built their own keyboard or preinstalled one of the others. They tested the Chinese market editions of devices, downloaded between August and November 2023.

What they found:

• Keyboards from eight of the nine vendors had flaws that let the researchers "completely reveal the contents of users' keystrokes in transit". Most could be exploited by "an entirely passive network eavesdropper", someone who only watches traffic.
• One keyboard sent keystrokes with no encryption at all. Most of the others relied on home made symmetric encryption rather than TLS, some with fixed keys built into the app, so anyone who analysed the app could decrypt the traffic. In several cases the traffic also carried the name of the app being typed into.
• The default keyboards on devices from three phone makers were vulnerable. Two more phone makers bundled a vulnerable keyboard that was not the default.
• Combining both studies, the researchers estimated that up to one billion users could be affected.
• One vendor's keyboards used TLS and had no transmission flaw that the researchers could find.

Was it fixed? Mostly, not entirely. As of 1 April 2024, the report says the phone makers had fixed the issues in their own keyboards, apart from keyboards built on one developer's engine, which had only the most serious issues addressed, or in one maker's case none. The researchers said they no longer had working exploits against any products except two: one maker's preinstalled default keyboard, which had no update path through that device's app store on the phone they tested, and an older standalone keyboard app that had not been updated since 2020 but was still available for download. One developer's keyboards still had cryptographic weaknesses that the researchers could not fully exploit at the time. Citizen Lab advised users of the two still vulnerable products to switch keyboards immediately.

The report also found that on some phones the keyboard fix arrived only after the operating system was fully updated.

What the research recommends

Citizen Lab recommends that users keep keyboards and operating systems updated and that at risk users "consider switching from a cloud-based keyboard app to one that operates entirely on-device". It tells keyboard developers to use standard protocols such as TLS or QUIC, and recommends that Android "implement sandboxing by default for keyboard apps, similar to iOS", so a keyboard cannot send network traffic until the user grants full access.

These studies covered cloud pinyin keyboards in one market. They do not show that every cloud keyboard leaks. They do show that cloud prediction sends live keystrokes over the network, and the user cannot see how well that connection is protected.

How enterprises control keyboards

On work phones, one permissive keyboard can see email, chat and admin consoles. Android and iOS handle this differently.

Android Enterprise: allowlist input methods

Android has had an input method allowlist since API level 21 (Android 5.0). DevicePolicyManager.setPermittedInputMethods lets a device owner or profile owner, or a holder of the MANAGE_DEVICE_POLICY_INPUT_METHODS permission, set which input methods the user may enable. Google's reference spells out the behaviour:

• By default the user can use any input method.
• Pass a list of package names, and input methods not on the list and not part of the system cannot be enabled. Any non system keyboard that is already enabled must be in the list for the call to succeed.
• Pass an empty list, and only the system's own input methods are allowed. Pass null to remove the restriction.
• System input methods are always available. The policy cannot remove them.

The work profile case has a privacy twist. On an organisation owned device with a work profile, the profile owner can apply the policy to the personal profile through the parent instance, but only as all or nothing: permit every input method, or only system ones. Google says this is "to prevent the caller from learning which packages are installed on the personal side".

If your organisation uses the Android Management API, the equivalent is the permittedInputMethods policy field. Google's reference says that if it is present, only input methods from listed packages are permitted, and if the list is empty, only system input methods are permitted. Our post on Android Enterprise modes, work profile, fully managed and dedicated explains which mode gives an admin which powers.

iOS and iPadOS: feature controls and app level refusal

Apple's published MDM restrictions schema (the com.apple.applicationaccess payload in Apple's device management repository) has long had keyboard feature keys: allowAutoCorrection, allowPredictiveKeyboard, allowSpellCheck, allowContinuousPathKeyboard, allowKeyboardShortcuts and allowDictation. The schema now marks these as deprecated in favour of a declarative management configuration, com.apple.configuration.keyboard.settings, which the schema lists from iOS 26.4 for supervised devices. Its keys are AllowAutoCorrection, AllowDefinitionLookup, AllowDictation, AllowMathKeyboardSuggestions, AllowPredictiveText, AllowSlideToType, AllowSpellCheck and AllowTextReplacement, each defaulting to true.

For dictation that must not leave the device, the restrictions schema has forceOnDeviceOnlyDictation (introduced in iOS 14.5), which "disables connections to Siri servers for the purposes of dictation". The schema marks it deprecated as of 26.4 and points to the com.apple.configuration.intelligence.settings declaration instead.

We did not find a key in Apple's published restrictions schema that blocks third party keyboards device wide. Apple documents app level control instead: apps can reject custom keyboards through shouldAllowExtensionPointIdentifier, and a Full Access keyboard works with managed apps only if it supports MDM. For a hard policy, ask your MDM provider what it exposes and have internal apps reject custom keyboards. Our post on Apple User Enrollment and what MDM can and cannot do covers the limits on personally owned iPhones.

Keyboard types compared

Step by step: lock down the keyboards on your phone

These steps change settings and remove apps, not data you cannot get back, with one exception: deleting learned words cannot be undone, so your suggestions start over.

Step 1: list the keyboards on your iPhone

1. Open Settings, tap General, then Keyboard, then Keyboards. Apple's iPhone User Guide uses this path.
2. To remove one, swipe left on it and tap Delete. To remove it from the phone entirely, delete the app that contains it.

Step 2: turn off Full Access you do not need

1. In the same Keyboards screen, tap a third party keyboard.
2. If it shows "Allow Full Access", turn it off unless a feature you rely on needs it.
3. Type with it. Under Guideline 4.4.1 basic typing must still work. Decide whether any feature you lose is worth network access to your keystrokes.

Step 3: check dictation and clear the iPhone dictionary

1. Open Settings, General, Keyboard. Apple says this screen indicates whether dictation is processed on the device. If it is not, decide whether you want dictation on.
2. To clear words you taught the system keyboard, open Settings, General, Transfer or Reset iPhone, Reset, then Reset Keyboard Dictionary. Do not tap Erase All Content and Settings, which Apple warns removes all your content.

Step 4: list the keyboards on your Android phone

1. Open Settings, System, Language and input (on some versions Keyboard), then On-screen keyboard. This is the path Google's Gboard help uses. Menu names vary by maker.
2. Turn off any keyboard you do not use. If a keyboard is an app you installed, uninstall it from the app's info page.
3. If you are a developer or administrator with USB debugging on a test device, list third party packages with the package manager and look for keyboards you do not recognise:

# List third party packages on a connected device (Android developer tools)
adb shell pm list packages -3

# List system packages, which include preinstalled keyboards
adb shell pm list packages -s

A keyboard preinstalled by the phone maker appears under -s, not -3, which is why it is easy to forget.

Step 5: turn off cloud features you do not want on Android

1. Open the keyboard's settings from the keyboard itself (Gboard shows a settings icon at the top of the keyboard).
2. Look for voice typing, search, GIF or sticker search, translation, cloud prediction and sync. Turn off the ones you do not use.
3. On Gboard, open Privacy. Decide on "Personalize for you" and "Improve for everyone" (federated learning, on by default per Google). Decline audio snippet donation if you do not want snippets stored and possibly reviewed.

Step 6: clear learned words on Android

On Gboard, Google documents two routes: keyboard Settings, Dictionary, Delete learned words (confirm with the number shown), or keyboard Settings, Privacy, Delete learned words and data, which clears all on device data Gboard saved. Other keyboards usually have a similar option in their privacy or dictionary settings.

Step 7: check the work profile

1. If your phone has a work profile, open the keyboard list again and look for a separate work section or work badge.
2. If your employer allowlists keyboards, unapproved keyboards will not enable in the work profile. That is policy, not a fault.
3. If you are the admin, set an allowlist. A minimal device policy controller call looks like this:

// Profile owner or device owner: allow only one approved keyboard plus system keyboards
val dpm = context.getSystemService(DevicePolicyManager::class.java)
val ok = dpm.setPermittedInputMethods(adminComponent, listOf("com.example.approvedkeyboard"))
// Empty list = system keyboards only. null = no restriction.

Step 8 (app developers): protect the fields you own

If you build mobile apps, you control part of this risk. On iOS, mark every password and secret field secure so third party keyboards are swapped out, and consider rejecting custom keyboards in high risk apps:

// UIApplicationDelegate: refuse third party keyboards in this app
func application(_ application: UIApplication,
                 shouldAllowExtensionPointIdentifier extensionPointIdentifier: UIApplication.ExtensionPointIdentifier) -> Bool {
    return extensionPointIdentifier != .keyboard
}

// Secret fields: the system keyboard replaces custom keyboards here
passwordField.isSecureTextEntry = true

On Android, set the right input type and ask keyboards not to learn from sensitive fields, while remembering that Google says the flag may be ignored:

codeField.inputType = InputType.TYPE_CLASS_TEXT or InputType.TYPE_TEXT_VARIATION_PASSWORD
codeField.imeOptions = codeField.imeOptions or EditorInfo.IME_FLAG_NO_PERSONALIZED_LEARNING

When your app copies a secret to the clipboard on Android 13 or later, set ClipDescription.EXTRA_IS_SENSITIVE on the clip so the system hides its preview.

Common mistakes

• Granting Full Access for a theme. Many keyboards ask for Full Access to sync themes or stickers from their app. The cost is network access to everything you type with that keyboard. Apple's rules say basic typing must work without it.
• Assuming password fields are protected everywhere. On iOS, only fields the app marked as secure get the system keyboard swap. On Android there is no swap at all; the protection depends on the keyboard respecting the password input type.
• Ignoring keyboards bundled by phone makers. Citizen Lab found vulnerable default keyboards on three makers' phones, and on one phone the keyboard had no update path through the app store. A preinstalled keyboard shows up as a system package, so it is easy to miss.
• Treating "encrypted" as "safe". Most of the keyboards in the 2024 study encrypted their traffic, just badly. Standard TLS is the baseline the researchers recommended.
• Forgetting the search box inside the keyboard. Keyboard search and GIF lookup send what you type into them.
• Thinking a dictionary reset clears everything. It does not delete donated audio snippets or data synced to a keyboard's cloud account.
• Relying on the "do not learn" flag as a control. IME_FLAG_NO_PERSONALIZED_LEARNING is a request. Do not build compliance arguments on it.
• Leaving old keyboards enabled. A keyboard you tried once still sits in the switcher and can be picked by accident in a sensitive field.

If you are worried that something on your phone is already logging keystrokes, our checklist on how to detect a keylogger on your phone covers the signs and the steps on both platforms.

Where Safeguard fits, honestly

Safeguard does not inspect keyboard apps, read keyboard traffic, or manage phones. It will not tell you whether a keyboard on your phone is safe. Where it does fit is on the other side of the screen: if your team builds mobile apps, the fields your users type secrets into, and the libraries your app ships, are your responsibility. Safeguard scans the dependencies in your repositories and app builds against vulnerability databases, shows which projects contain a given component and version, ranks findings with reachability analysis, and can open fix pull requests when a fixed version exists (autonomous remediation ships switched off). Our guide to an SBOM for mobile applications on iOS and Android explains how to list what your app actually contains.

FAQ

Can a keyboard app see my passwords?

On iPhone, a third party keyboard does not receive input in fields that the app marks as secure: iOS swaps in the system keyboard. It can see a password typed into a field the app did not mark secure. On Android, the keyboard you choose types into password fields. It is told the field is a password field and is expected not to store or show the text, but the system does not block it.

What does "Allow Full Access" mean on iPhone?

It lets a third party keyboard leave its sandbox. Apple's documentation says that with Full Access a keyboard can send keystrokes for server side processing, share a container with its app, use Location Services and Contacts with your permission, use iCloud, and work in managed apps if it supports MDM. Without it, Apple says keystrokes go only to the app you are typing in.

Does Gboard send what I type to Google?

Google's Gboard help says Gboard sends your searches, usage statistics, and your voice when you use talk-to-text, and does not send anything else you type, such as passwords or chats. Saved words stay on the device. Federated learning sends model updates, not text, and is on by default with a switch to turn it off.

Is iPhone dictation processed on the device?

Often, in many languages. Apple says Keyboard Settings shows whether audio and transcripts stay on the device; if not, Apple processes dictation on its servers without storing it unless you opt in to Improve Siri and Dictation.

Were the keyboard vulnerabilities Citizen Lab found ever fixed?

Mostly. The 2023 flaws were fixed by 20 July 2023. After the 2024 study most vendors fixed theirs, but as of 1 April 2024 two products still had working exploits. Keep keyboards and the operating system updated.

What is federated learning in a keyboard?

Your phone trains the prediction model on your typing locally and sends only a model update, which is combined with updates from many other phones. The text stays on the device.

How do I delete what my keyboard has learned?

On iPhone, Settings, General, Transfer or Reset iPhone, Reset, Reset Keyboard Dictionary clears words you added to the system keyboard. Third party keyboards have their own settings. On Gboard, use Dictionary, Delete learned words, or Privacy, Delete learned words and data.

Can my employer stop me installing a keyboard?

On Android, yes, for devices or profiles they manage: Android Enterprise can permit only listed keyboards or only system keyboards. On a personal profile of an organisation owned device, the choice is limited to all or system only. On iPhone, Apple's MDM schema controls keyboard features rather than blocking third party keyboards outright, and apps can refuse custom keyboards themselves.

Keyboards themselves are outside what Safeguard scans, so the fit here is indirect. But the apps your team ships to phones carry open source libraries that need the same patch discipline, and the fields those apps put in front of a keyboard are only as safe as the code behind them.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

None of these demos inspect a keyboard, read keyboard traffic or change phone settings. They show how Safeguard handles the code your team builds, including the mobile apps where users type their secrets.

The first demo is a real Safeguard CLI session. Asked to fix a lodash CVE, the assistant reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. The same flow applies to a JavaScript dependency in a React Native or web view based mobile app, whenever a fixed version exists.

Click through it at your own pace, or open it full screen.

The second demo is a real Android session with the Safeguard phone app. It sends work to a computer running the CLI, and you approve the command on the phone with Allow once, Allow for turn or Deny. It is a reminder that a phone can be part of a careful workflow: the decision to run something stays with you, on a screen you control.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. A mobile team can then ask about the components and vulnerabilities in its app projects from inside Claude, within the tool permissions you set.

Click through it at your own pace, or open it full screen.

To try the CLI, download Safeguard and follow the CLI documentation.

Quick check

Sources

• Android Developers: InputMethodService reference
• Android Developers: EditorInfo reference (IME_FLAG_NO_PERSONALIZED_LEARNING)
• Android Developers: InputConnection reference
• Android Developers: Create an input method
• Android Developers: Privacy changes in Android 10
• Android Developers: Copy and paste (Android 13 sensitive content)
• Android Developers: DevicePolicyManager reference (setPermittedInputMethods)
• Android Developers: Settings.Secure reference
• Android Developers: Android Debug Bridge (package manager commands)
• Google for Developers: Android Management API, enterprises.policies
• Apple Developer: Creating a custom keyboard
• Apple Developer: Configuring open access for a custom keyboard
• Apple Developer: UIInputViewController hasFullAccess
• Apple Developer: application(_:shouldAllowExtensionPointIdentifier:)
• Apple Developer Documentation Archive: App Extension Programming Guide, Custom Keyboard
• Apple Developer: App Review Guidelines
• Apple device management schema: Restrictions payload (com.apple.applicationaccess)
• Apple device management schema: Keyboard settings declaration
• Apple Support: Add or change keyboards on iPhone
• Apple Support: Reset iPhone settings
• Apple Support: Dictate text on iPhone
• Apple Legal: Siri, Dictation and Privacy
• Gboard Help: Fix problems with Gboard (what Gboard sends to Google)
• Gboard Help: Learn how Gboard gets better
• Gboard Help: Use advanced voice typing features
• Hard et al., Federated Learning for Mobile Keyboard Prediction (arXiv:1811.03604)
• Google Research: Federated Learning, Collaborative Machine Learning without Centralized Training Data (6 April 2017)
• Citizen Lab: The not-so-silent type, vulnerabilities across keyboard apps (23 April 2024)
• Citizen Lab: Report No. 170, keyboard encryption vulnerabilities expose keypresses to network eavesdropping (9 August 2023)

Last reviewed: 25 October 2026. Keyboard features and platform settings change with each release; check Apple's and Google's documentation for the version on your phone.