{
	"id": "52bcbcec-6838-4297-ab89-2d10ff9c4f35",
	"created_at": "2026-04-06T01:32:25.330312Z",
	"updated_at": "2026-04-10T03:20:34.468502Z",
	"deleted_at": null,
	"sha1_hash": "a195c8bc8e394af3911c566b37fe27f71f9e30a3",
	"title": "Security of Third-Party Keyboard Apps on Mobile Devices",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 341585,
	"plain_text": "Security of Third-Party Keyboard Apps on Mobile Devices\r\nBy Lenny Zeltser\r\nPublished: 2014-09-24 · Archived: 2026-04-06 01:12:04 UTC\r\nThird-party mobile keyboards with network access can capture keystrokes and transmit them to developers'\r\nservers, creating keylogger-like risks. Keyboard developers vary widely in their security transparency—some like\r\nGoogle clearly explain data practices while others provide only vague privacy policies that users cannot\r\nmeaningfully evaluate.\r\nMajor mobile device platforms allow users to replace built-in keyboard apps with third-party alternatives, which\r\nhave the potential to capture, leak and misuse the keystroke data they process. Before enabling the apps, their\r\nusers should understand the security repercussions of third-party keyboards, along with the safeguards\r\nimplemented by their developers.\r\nThird-party keyboards received a boost of attention when Apple made it possible to implement such apps starting\r\nwith iOS version 8, though this capability have existed on Android for a while. iOS places greater restrictions on\r\nkeyboards than do Android operating systems; however, even Apple cannot control what keyboard developers do\r\nwith keystroke data if users allow these apps to communicate over the network.\r\nGranting Network Access to the Keyboard App\r\nThe primary security concerns related to keyboard applications are associated with their ability to transmit the\r\nuser’s keystrokes and potentially other sensitive data to developers’ servers. On iOS, this is possible if the user\r\ngrants the app “full access,” as encouraged or required by the application.\r\nThe notion of “full access” is equivalent to the term “network access” that Apple’s App Extension Programming\r\nGuide discusses when explaining how to build a custom keyboard. According to the guide, network access is\r\ndisabled by default. Once enabled by the user, this capability allows the keyboard to access “Location Services\r\nhttps://zeltser.com/third-party-keyboards-security/\r\nPage 1 of 7\n\nand Address Book, with user permission,” “send keystrokes and other input events for server-side processing,”\r\nand perform additional actions that would otherwise be unavailable.\r\nA legitimate keyboard app might send keystrokes to its server to perform intelligent analysis that is best conducted\r\nin the “cloud,” such as predict upcoming letters, store user typing patterns or perform large-scale lexicon\r\nanalytics. Some third-party keyboards will function without their users granting them “full access;” however this\r\nwill disable some of the features that might have drawn the users to the app in the first place.\r\nGuidelines for Networked Keyboard Apps\r\nApple encourages keyboard developers to “establish and maintain user trust” by understanding and following\r\n“privacy best practices” and the associated iOS program requirements, guidelines and license agreements. For\r\ninstance, if the keyboard sends keystroke data to the provider’s server, Apple asks the developer to not store the\r\ndata “except to provide services that are obvious to the user.” Presumably, Apple’s app review process catches\r\nblatant violations of such guidelines; however, once the keyboard transmits user data off the phone, there is little\r\nApple can do to assess or enforce developers’ security measures. (I haven’t been able to locate keyboard-related\r\nsecurity guidelines for the Android ecosystem, but I suspect they are not stronger than those outlined by Apple.)\r\nUsers of third-party keyboards should not count on mobile OS providers to enforce security practices on server-side keyboard data processing. Instead, they should decide whether they trust the keyboard developer with their\r\ndata, perhaps on the basis of their perception of the developer’s brand and public security statements.\r\nPotential for Inadvertent Data Leakage\r\nEven if the keyboard developer intends to safeguard the data their app captures, there is the possibility and a bug\r\nin the implementation or design of the keyboard will inadvertently expose sensitive data. For example, in July\r\n2016, some SwiftKey users reported that “that their keyboards were populating with other people’s email\r\naddresses and searched phrases.” This might have been caused by SwiftKey’s language model improperly cross-pollinating the terms learned from one user to others. SwiftKey didn’t offer much of an explanation for this issue\r\nbeyond a terse statement. Another illustrative example of the risks posed by third-party keyboard comes from the\r\nhttps://zeltser.com/third-party-keyboards-security/\r\nPage 2 of 7\n\naccidental leak of sensitive data about 31 million users of the ai.type mobile keyboard app. This breach reportedly\r\ncontained risky information about the keyboard’s users, which demonstrated the type of data third-party keyboards\r\ncan capture and expose:\r\nPhone number, email address and full name\r\nDevice characteristics, including model, IMSI and IMEI numbers\r\nSocial network profile details\r\nPhysical location information\r\nAddress book contact records\r\nSecurity and Privacy Statements from Keyboard Developers\r\nI looked at the security and privacy statements published by the developers of three popular keyboard apps that are\r\navailable for mobile devices: SwiftKey, Gboard, Fleksy and Swype. Their developers differ in their explanation of\r\nhow the safeguard users’ data.\r\nSwiftKey\r\nSwiftKey, which is now owned by Microsoft, publishes a high-level overview of its data security and privacy\r\npractices. For users who opt into the SwiftKey Cloud feature of the product, the company collects “information\r\nconcerning the words and phrases” that users utilize. The company calls this Language Modeling Data and\r\nexplains that it is used to provide users with “personalization, prediction synchronization and backup.” Fields that\r\nwebsite or app developers designate as denoting a password or payment information are excluded from such\r\ncollection.\r\nSwiftKey states that the data transferred to SwiftKey Cloud is transmitted to their servers “over encrypted\r\nchannels” and is stored in a “fully encrypted” manner. The company also points out that its data protection\r\npractices are governed by “stringent EU privacy protection laws” and mentions the (now weakened) Safe Harbor\r\nprinciples. The company also states that data of users who don’t enable SwiftKey Cloud is not transferred out of\r\ntheir devices.\r\nUsers of the SwiftKey iOS app are instructed to grant the keyboard full access. Once this is accomplished, the user\r\nhas the option of enabling SwiftKey Cloud “to enhance SwiftKey’s learning” by signing in with their Facebook or\r\nGmail credentials. To discover security implications of enabling this feature, the user had to dig into the details\r\navailable by clicking “Privacy policy” and “Find out more” links.\r\nhttps://zeltser.com/third-party-keyboards-security/\r\nPage 3 of 7\n\nUnfortunately, SwiftKey on iOS doesn’t function at all until the user grants it full access. The user needs to trust\r\nSwiftKey that they won’t send data off the mobile device unless SwiftCloud is enabled.\r\nGboard\r\nThe most attractive feature of Google’s Gboard keyboard is probably the web-searching interface, which allows its\r\nuser to submit search queries to Google without explicitly switching to a web browser.\r\nhttps://zeltser.com/third-party-keyboards-security/\r\nPage 4 of 7\n\nThe user needs to grant Gboard full access so that Google can receive the person’s search terms. However, Google\r\nstates that nothing else the person types is sent to Google. This is explained to the user from within the app during\r\nthe setup process. Also, the statement is reiterated in the app’s privacy policy, which is refreshingly easy to\r\nunderstand. It states:\r\n“Your searches are sent to Google’s web servers to give you search results.\r\nUsage statistics are sent to let us know which features are used most often and to help us\r\nunderstand problems.”\r\nGlenn Fleishman confirmed that Gboard operates in a manner consistent with this statement. He used a network\r\nsniffer to examine what data Gboard transmits to Google’s servers. When typing in Gboard, he observed “that no\r\ndata was being sent at all between iOS and the Internet while I typed. I could then tap the G icon and perform\r\nsearches, and watch data get sent back and forth.”\r\nFleksy\r\nFleksy used the term Language Modeling Data in its original Privacy Policy, explaining that it refers to data “such\r\nas common phrases or words that you use when typing with Fleksy.” As of this writing, Fleksy’s revised Privacy\r\nPolicy doesn’t use this term, and instead makes general claims such as the “Data concerning the User is collected\r\nto allow the Owner to provide its services” and purposes such as infrastructure monitoring, analytics, etc.\r\nThough the policy at the first glance appears comprehensive, I couldn’t find any details related to Fleksy’s\r\nlanguage modeling data or security measures beyond generic, vague statements. The company provided some\r\nclarification regarding the type of data its app uses and accesses in its FAQ.\r\nThe company’s CEO Olivier Plante made a public commitment to protect users’ privacy, stating that the company\r\n“purposefully built our technology and algorithms to remain processed locally, and never rely on server-side\r\npersonal data processing.” He pointed out that while most of Fleksy’s competitors make money by mining user\r\ndata “for various purposes such as advertising,” personal voice assistants and so on, the company’s business\r\nmodel is based on the purchases users make inside Fleksy’s app.\r\nWhen installing Fleksy’s app, I was encouraged to enable “Customization” by granting the keyboard full access,\r\nstating that “keyboard apps require full access to sync your preferences.”\r\nhttps://zeltser.com/third-party-keyboards-security/\r\nPage 5 of 7\n\nSwype\r\nSwype is another popular keyboard for mobile devices. It’s developed by a company called Nuance.\r\nUnfortunately, I could not find any information about this app’s security practices beyond a knowledgebase article\r\nfor its Android keyboard, which stated that the company “does not collect personal information such as credit card\r\nnumbers” and “suppresses all intelligent learning and personal dictionary addition functionality when used in a\r\npassword field.” The company’s privacy policy contains generic statements such as:\r\n“Nuance may share Personal Information within Nuance to fulfill its obligations to you and operate its\r\nbusiness consistent with this Privacy Policy and applicable data protection law.”\r\nConclusions and Implications\r\nThird-party keyboards for mobile devices offer features that improve upon some aspects of built-in keyboards.\r\nHowever, to enjoy such innovations, the users generally need to grant keyboard apps network access. This means\r\nthat the users need to accept the following risks:\r\nThe users need to be OK allowing keyboard developers to collect and store on their servers Language\r\nModeling Data without fully understanding the meaning of this term or its privacy and security\r\nimplications. The collection of such data is generally acknowledged by the keyboard developers, though\r\nthey offer almost no details regarding how this data is safeguarded beyond referring to “encryption.”\r\nThe users need to trust the keyboard developer not to capture keystrokes and other sensitive data beyond\r\nLanguage Modeling Data. Doing this could be done on purpose by a malicious keyboard app or by\r\naccident by an otherwise benign application. In this case, the keyboard could act as a powerful keylogger\r\nfor the mobile device.\r\nUsers might assume that the guardians of their mobile OS, be they Google, Apple, Samsung, etc., might protect\r\nthem from malicious or accidental misuse of keystroke data and network access. However, such firms have no\r\ndirect control over what happens once the data leaves the mobile device. Keyboard developers should provide\r\nadditional details about their security practices to reassure users and consider how their apps might provide\r\ninnovative features in a manner that minimizes users’ risk and the apps’ need for network access. It’s unclear why\r\nhttps://zeltser.com/third-party-keyboards-security/\r\nPage 6 of 7\n\nSwiftKey cannot function (at least on iOS) without network access, why Fleksy doesn’t make it easier for users of\r\nits app to understand when data is sent to the company’s servers and why Nuance doesn’t discuss any of these\r\ntopics for its Swype keyboard on its website. I discussed this topic on the Science Friday radio show in the second\r\nhalf of the segment called Tracking the Hidden Trail Left by Your Smartphone.\r\nSource: https://zeltser.com/third-party-keyboards-security/\r\nhttps://zeltser.com/third-party-keyboards-security/\r\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://zeltser.com/third-party-keyboards-security/"
	],
	"report_names": [
		"third-party-keyboards-security"
	],
	"threat_actors": [],
	"ts_created_at": 1775439145,
	"ts_updated_at": 1775791234,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/a195c8bc8e394af3911c566b37fe27f71f9e30a3.pdf",
		"text": "https://archive.orkl.eu/a195c8bc8e394af3911c566b37fe27f71f9e30a3.txt",
		"img": "https://archive.orkl.eu/a195c8bc8e394af3911c566b37fe27f71f9e30a3.jpg"
	}
}