The ai.type breach, revisited

In December 2017, researchers at the Kromtech Security Center found a MongoDB database belonging to ai.type, a popular third-party keyboard for Android and iOS, sitting on the open internet with no password. It held 577 gigabytes. The story was reported by ZDNet first and then widely, and it is still the clearest public record of what a keyboard vendor can end up holding. Nearly a decade on, it is worth reading precisely, because it is usually retold imprecisely.

What was in the database

Have I Been Pwned, which indexed the dump, lists the compromised data types as: address book contacts, apps installed on devices, cellular network names, dates of birth, device information, email addresses, genders, geographic locations, IMEI numbers, IMSI numbers, IP addresses, names, phone numbers, profile photos, and social media profiles.

Kromtech put the number of records at 31,293,959. Have I Been Pwned lists 20.6 million unique email addresses, which is the count of distinct addresses rather than of rows, and both numbers are correct for what they count.

The developer had left the database unprotected. Per the reporting, it was secured after Kromtech and ZDNet made repeated contact.

What was not in it, as far as the record shows

This is the part that gets lost. The coverage I could find does not indicate that typed text or keystrokes were in the exposed database. Android Police's report lists emails, phone numbers and locations and does not list typed text, while noting an earlier, separate 2011 concern that the app sent keystrokes to its servers. I am not going to claim the 2017 dump contained passwords, because the sources do not say it did.

What it contained was everything around the typing: who you are, who you know, where you are, what phone you have and what else is on it. A keyboard obtained all of that not by reading fields, but by holding permissions for contacts, phone state and location, and a network permission to send them with.

What it proves

Three things, and none of them is "keyboards are evil".

The server is the risk surface. The leak was not an interception, an exploit, or a rogue employee. It was a database with no password. The data was exposed because it existed somewhere other than the phones it came from. Every keyboard vendor that holds user data holds this risk, and the good ones spend real money on it. The only vendor that does not is one with nothing to secure.

Permissions are the inventory. The list of what leaked reads like a permission list: contacts, phone state, location, installed apps, network. A keyboard that does not hold the contacts permission cannot leak your address book, no matter what happens to its servers, because it never had it. Which keyboards ask for contacts, and what reason they give, is a separate post.

"Free" was the business. Kromtech's Bob Diachenko, quoted in the coverage, asked whether it "is really worth it for consumers to submit their data in exchange for free or discounted products or services that gain full access to their devices". That is the trade most keyboard apps still offer, and most people still take it without knowing the price was their contacts list.

What it does not prove

It does not prove that any particular keyboard today is doing what ai.type did. Most large vendors document their data flows and secure their servers, and their permission lists are on their Play listings for anyone to read. It also does not prove that a keyboard with no server is safe in every sense: a keyboard can still mishandle what it keeps on the phone, which is why what FrankenKeys stores locally is listed in the app with a wipe button beside each entry.

What it proves is narrower and more useful. The question "can a keyboard app read my passwords" has a technical answer: yes, every keyboard can read the field it is typing into. The question that matters is the next one, "and where can it send them", and the ai.type record is what the answer looks like when a vendor holds the network permission and a database and gets one configuration wrong.

How to read your own keyboard against this

1. Play listing, About this app, App permissions, See more. Count the entries that are about you: contacts, location, phone, camera, microphone.
2. Look under Other for "have full network access".
3. For each entry, find the vendor's stated reason. If there is none, that is the answer.
4. Consider what the union of those permissions would look like in a database with no password. That is the ai.type test, and it is fair to apply to any app, including this one.

The most quoted fact about the breach is the number. The most useful fact is the column headings.