Keyboard Apps and Predictive Text Privacy Guide: What Third-Party Keyboards Can See and Send

The keyboard is the one piece of software that sees almost everything a person types on a phone, including messages, search terms, customer data and sometimes credentials, so the choice of keyboard app is a privacy and data protection decision. Predictive text, autocorrect, swipe typing, translation and AI writing features all work by learning from what is typed, and some of them send text to a server to do it. This guide explains what iOS and Android allow third-party keyboards to see and send, what predictive text stores on the device, how organisations can restrict keyboards on managed devices and inside managed apps, and how developers keep sensitive fields away from untrusted keyboards. It is written for mobile and endpoint security teams, privacy officers and app developers.

Key takeaways

• A keyboard with network access can send keystrokes off the device. On iOS this requires the user to grant open access ("Allow Full Access"); on Android an input method is an app and can use the network like any other app.
• Secure fields are the main platform safeguard. iOS swaps in the system keyboard for secure text fields and phone pads; Android password input types suppress suggestions and caching, but the platform calls its no-learning flag a request, not a guarantee.
• Predictive text learns locally. Learned words and keyboard caches stay on the device unless a cloud feature sends them, and users or administrators can usually clear them.
• Cloud prediction needs strong transport security. Citizen Lab found in 2024 that eight of nine vendors' cloud-based pinyin keyboards it examined had flaws that could expose keystrokes to network eavesdroppers.
• Organisations have real controls: block third-party keyboards in managed apps, allowlist input methods on managed Android devices, and build apps that keep secrets on the system keyboard.

What a keyboard can see and send

A software keyboard receives each character before the app does. What it can do with that text depends on the platform's permission model and on the field the user is typing into.

Keystroke capture by malicious input software is tracked in MITRE ATT&CK for Mobile as T1417.001 Keylogging. The same capability that makes a legitimate keyboard useful is what makes a malicious or careless one dangerous. See the Keyloggers Guide for the wider threat.

iOS: open access and what it grants

Apple's App Extension Programming Guide sets out the custom keyboard model. By default a keyboard has no network access and cannot share a container with its containing app, and Apple states that a keyboard built without open access cannot send keystrokes back to the developer or anywhere else. A developer who sets RequestsOpenAccess in the extension's Info.plist asks the user for more. If the user turns on "Allow Full Access" for that keyboard (Settings, General, Keyboard, Keyboards), the keyboard gains:

• Network: the ability to send keystrokes, other input events and data over the network for server-side processing.
• Shared container: a shared container with the containing app, so learned data can move between the keyboard and the app.
• Clipboard: use of the UIPasteboard class.
• Other data: access to Location Services, contacts and the photo library, each still requiring the user's permission on first access; iCloud access.
• Managed app support: the ability to work with managed apps if the keyboard is designed to support MDM.

Apple's guidance to keyboard developers is to treat the autocorrect lexicon as private user data, not to keep keystroke or voice data longer than needed to return text or provide features they explain to the user, and not to use data for purposes that are not obvious to the user. These are developer obligations; the user has no technical way to verify them once full access is granted.

Limits that protect users regardless of full access: iOS replaces a custom keyboard with the system keyboard in secure text fields and in phone pad fields, and keyboard extensions have no microphone access. OWASP's mobile testing guide also records that the system keyboard caches autocorrect and spell check data in .dat files under /private/var/mobile/Library/Keyboard/, which matters for forensics and for apps that let sensitive text reach that cache.

Android: input methods are apps

On Android the keyboard is an input method service supplied by an app. Once a user enables it and selects it, it receives text from fields in other apps. Its access to the network, storage and microphone comes from the permissions the app holds, not from a separate keyboard-specific toggle, so judging an Android keyboard means judging the whole app and its developer.

• Field signals: apps mark sensitive fields with input types such as textPassword, numberPassword or textNoSuggestions. OWASP MASTG notes that password input types disable suggestions and caching for those fields.
• Personalised learning flag: EditorInfo.IME_FLAG_NO_PERSONALIZED_LEARNING (API level 26) asks the keyboard not to update typing history or its personalised language model. Android's own documentation says the flag is not a guarantee and some IMEs may not respect it.
• Manufacturer defaults: many devices ship with a manufacturer keyboard as the default rather than the platform keyboard. Its cloud features and update channel are part of the device's risk.

See the Android Security and Privacy Settings Guide and the Mobile App Permissions guide.

Predictive text: what is learned and where it lives

Google's Gboard help page is an example of the disclosure to look for. It says federated learning "doesn't send the text you speak or type to Google, but will send what it learns to Google", that it runs only while the phone charges, is on Wi-Fi and is not in use, that it is on by default and can be turned off, and that "Delete learned words and data" clears what Gboard holds on the device. Google first described federated learning for Gboard query suggestions in 2017, with secure aggregation designed so the server only sees averaged updates. See the Federated Learning Privacy guide for the limits of that model.

Cloud keyboards: the 2024 Citizen Lab findings

Citizen Lab's report "The Not-So-Silent Type" (23 April 2024) examined cloud-based pinyin keyboard apps from nine vendors: Baidu, Honor, Huawei, iFlytek, OPPO, Samsung, Tencent, Vivo and Xiaomi. It found that eight of the nine had vulnerabilities that could let a passive network eavesdropper read users' keystrokes, because typed text was sent to cloud servers without encryption or with weak, home-made encryption. Huawei was the only vendor where no issue was found. The authors estimated that up to one billion users could have been exposed, counting their earlier Sogou research. As of 1 April 2024, working exploits remained for two products and other issues had been fixed or partly addressed.

The lessons go beyond one market:

• Cloud prediction moves keystrokes off the device and makes the vendor's transport security part of your data protection.
• Default keyboards matter: several of the affected apps were the default keyboard on the device, not something the user chose.
• Update hygiene is a control: the report advises users to keep keyboard apps and the operating system updated and to consider keyboards that work entirely on the device, especially if they are at risk.

AI keyboards and writing assistants

Keyboards that rewrite, summarise, translate or answer questions inside any text field are a form of generative AI use at the point of entry. Whatever is selected or typed into the feature may be sent to a model provider, which can include customer records, contract text or source code pasted into a work app. Treat these keyboards as AI services: check what is sent, where it is processed, how long it is kept and whether it is used for training, and apply the same approval process as other AI tools. See the Shadow AI Discovery Guide and the Generative AI Data Loss Prevention Guide.

Enterprise controls

On personal devices enrolled under BYOD, keyboard choice is usually the user's. App protection policies are the realistic control there, because they protect work data inside managed apps without controlling the whole phone. See the Mobile Device Management Security Guide and the BYOD Policy Template.

Developer controls for sensitive fields

OWASP MASTG best practice MASTG-BEST-0069, "Keep Sensitive Input on the System Keyboard", recommends secure fields for passwords, PINs, one-time passcodes and payment data, and app-wide rejection only where an app genuinely needs it. Code review and testing should confirm every credential, one-time code and card field uses these settings. See the iOS App Security Guide and the Kotlin and Android Secure Coding Guide.

Decision guidance

• Fully managed corporate devices: allowlist the system keyboard and a small number of reviewed keyboards; block keyboard apps that require full access unless a business need is documented.
• BYOD: do not try to control the personal keyboard; block third-party keyboards inside managed apps and restrict copy and paste out of them.
• High-risk users (executives, journalists, staff in sensitive roles): prefer on-device keyboards with cloud features off. See the Mobile Communications Protection for High-Risk Individuals Guide.
• Accessibility and language needs: some users depend on specific keyboards. Review and approve them rather than banning all third-party keyboards; an app-wide block can exclude people.
• Small organisations: start with user guidance and app protection policies for email and file apps; device-wide allowlisting can follow when devices are fully managed.

Assessing a keyboard app

1. Does it need network access or full access for its core function, or only for optional cloud features?
2. What text is sent to servers, when, and is that stated in its privacy policy and settings?
3. Is transport encryption standard TLS, and does the vendor have a security contact and update record?
4. How long is text, voice or learned data retained, and is it used for model training?
5. Can learned data be deleted on the device and on the server?
6. Where is the vendor based and which jurisdiction governs access to its data?
7. Does it include AI features that send selected text to a third-party model provider?

Rolling out keyboard controls

1. Inventory: use MDM app inventory to list installed keyboard apps on managed devices and identify which have full access or network features.
2. Policy: agree which keyboards are approved and which data must never be typed into a third-party keyboard.
3. Pilot: apply the keyboard block in app protection policies to a pilot group and measure support calls, especially from users of language and accessibility keyboards.
4. Enforce: extend to all managed apps; on fully managed Android devices apply permittedInputMethods.
5. Developers: add secure-field checks to code review and mobile testing for internal apps.
6. Rollback: if a block causes accessibility or business problems, return the affected group to allowed and add the specific keyboard to the approved list rather than lifting the block for everyone.

Detection and measurement

• Inventory drift: alert when an unapproved keyboard app appears on a managed device.
• Policy compliance: report devices and apps where the keyboard restriction is not applied, including apps on older SDK versions.
• App testing results: track sensitive fields found without secure or no-suggestion input types in internal apps.

Metrics: percentage of managed devices running only approved keyboards; percentage of managed apps with the third-party keyboard block applied; number of internal app fields failing secure-input checks; number of approved keyboard exceptions and their review date; time to remove a keyboard found to have a security flaw.

Framework mapping

Common failure patterns

• Full access granted without thought: users enable "Allow Full Access" because a theme or GIF feature asks for it.
• Passwords in ordinary fields: internal apps collect PINs or recovery codes in standard text fields, so they reach third-party keyboards and caches.
• Relying on the no-learning flag: treating IME_FLAG_NO_PERSONALIZED_LEARNING as a guarantee when the platform says it is a request.
• Ignoring the default keyboard: reviewing only keyboards users install, while the manufacturer's default sends text to the cloud.
• Blanket bans: blocking all third-party keyboards everywhere and breaking access for users who need language or accessibility keyboards.

Practitioner checklist

• Inventory keyboard apps on managed devices, including manufacturer defaults.
• Publish an approved keyboard list with a documented review of each keyboard's cloud features.
• Block third-party keyboards in managed apps on iOS and allowlist input methods on managed Android.
• Restrict copy and paste from managed apps to unmanaged apps where data sensitivity requires it.
• Require secure or no-suggestion input types for credentials, one-time codes and card data in internal apps.
• Treat AI keyboards and writing assistants as AI services under the AI use policy.
• Tell users what "Allow Full Access" means and how to clear learned words.
• Keep keyboard apps and operating systems on supported, updated versions.

Standards and references

• Apple: App Extension Programming Guide, Custom Keyboard
• Android Developers: EditorInfo reference
• OWASP: MASTG-BEST-0069 Keep Sensitive Input on the System Keyboard
• OWASP: Mobile Application Security Verification Standard
• Microsoft: iOS/iPadOS app protection policy settings
• Google: Android Management API, enterprises.policies
• Citizen Lab: The Not-So-Silent Type
• Google: Learn how Gboard gets better

Related NHI Mgmt Group resources: Mobile App Permissions · iPhone Security and Privacy Settings Guide · Android Security and Privacy Settings Guide · Keyloggers Guide · Mobile Device Management Security Guide