TEARDOWN · 2026-09-06 · the FrankenKeys log

Keyboards that ask for contacts or a camera, and why

Which Android keyboards request contacts, camera or accounts, and the reasons their own documentation gives. The point is that a reason should exist.

2026-09-06 · by Corey Redwine · android keyboard privacy

A keyboard needs, at most, vibration and a microphone to be a keyboard. Anything past that is a feature, and a feature should come with a stated reason. This post lists the keyboards whose listings or documentation show a permission about you, contacts, camera, accounts, and the reason the vendor gives. Where I could not find a first-party reason, I say so rather than inventing one. Read on 2026-09-06.

Contacts

Reading your contacts is the most common extra permission on keyboards, and the usual reason is name suggestion: if your friend is called Siobhán, the keyboard would like to stop correcting her.

Microsoft SwiftKey. Microsoft's permissions page lists "Find accounts on this device", explained as making it "easier for you to link accounts such as Google and Microsoft to your Microsoft SwiftKey Keyboard". That is an accounts permission rather than contacts, and the page gives its reason.

HeliBoard, AnySoftKeyboard, Indic Keyboard. All three F-Droid listings show "read your contacts". These are open-source keyboards without a permissions page of their own, so I have not quoted a reason for each; the F-Droid listing is the first-party fact, and the public source is where the reason lives if you want to confirm it.

Gboard. I could not find a Google-controlled page that lists Gboard's manifest permissions or states a reason for a contacts permission, so there is no Gboard row here. The Play listing shows its permissions inside the Play app, and you can read them there yourself: About this app, App permissions, See more.

Camera

Microsoft SwiftKey. Microsoft's page lists "Take pictures and record video", explained as "access your device's camera for features that require capturing images or video". The same page notes the camera feature is requested dynamically, after install, rather than at install time.

That is a reason, and Microsoft gives it. Whether you want your keyboard to have a camera feature is a separate question from whether the request is honest, and this post is only about the second.

Microphone

Every keyboard with voice typing asks for it, FrankenKeys included. SwiftKey's page: "access the microphone when you use voice typing or any features requiring audio input". FrankenKeys: the same, with the audio going to the system recogniser. This is the one permission about you that a keyboard has a plain reason to hold, provided the audio path is documented.

Location

I could not find a first-party document from any keyboard vendor in this list stating a location permission and its reason, so there is no row. If you find a keyboard whose listing shows location, the test is the same: find the vendor's sentence. If there is none, that is your answer.

Network, again

SwiftKey's page lists "Full Internet access" with the reason "download language models so that you can benefit from our prediction technology". That is a documented reason for the network permission, and it is the reason every cloud-dictionary keyboard has. FrankenKeys ships its thirty dictionaries in the package instead, which is why it does not need the permission and does not hold it. Neither choice is dishonest; they are different products.

N/I

FrankenKeys holds no contacts, camera, accounts or location permission, and no network permission. The five it does hold are on the permissions page with a reason each. The Play listing's App permissions detail shows the same list; the verify guide shows it on the phone.

The test I am proposing

Not "does this keyboard ask for anything beyond a microphone", because some good features need more. The test is: for every permission on the listing that is about you, can you find one sentence, on a page the vendor controls, that says what it is for?

Microsoft passes this test for every permission on its list. The open-source keyboards pass it by being open. Where a keyboard fails it, you have learned something without needing to decompile anything.

The reason the test matters is the ai.type breach: what leaked in 2017 was exactly the set of things a keyboard's extra permissions let it collect, and a database that should not have existed. A permission with a reason can still leak. A permission with no reason should not be there.

What FrankenKeys gives up by this rule

No contact-name suggestions. Your friend's name gets learned once you have typed it, like any other unknown word, and until then autocorrect may have an opinion. No camera feature, no account linking, no cloud sync, no location-aware anything. The no-server post is the full list of what that costs.

Sources read on 2026-09-06

  • support.microsoft.com/en-us/swiftkey-keyboard/microsoft-swiftkey-keyboard-permissions: every SwiftKey permission and its stated reason.
  • f-droid.org listings for helium314.keyboard, com.menny.android.anysoftkeyboard, org.smc.inputmethod.indic: the "read your contacts" entries.

A reason is not a defence. It is the minimum. Most keyboards clear it; the ones that do not are the ones to read twice.