AccessibilityServices, Play Store Bans, and API Design

TL;DR: When designing an API, keep features with privacy and security ramifications separate from other features, such that both you and developers using the API have a very clear sense of what is and is not sensitive.

Many of you may have heard about Google’s threats to remove apps from the Play Store that have an AccessibilityService that is not primarily for accessibility. Many outlets reported on this, including XDA Developers and Ars Technica. According to the purported emails, Google is stating that if your app has requested the BIND_ACCESSIBILITY_SERVICE permission:

you must explain to users how your app is using the android.permission.BIND_ACCESSIBILITY_SERVICE to help users with disabilities use Android devices and apps

Later, the email states that you should remove the app if “the permission is being used for something other than helping users with disabilities use Android devices and apps”.

On the one hand, I completely understand the rationale for instituting this sort of ban. Accessibility APIs have been a privacy and security problem for some time, even if many people are only recently noticing it. It is easier for Google to whitelist various apps that have legitimate need to use those APIs than it is to root out all malicious uses.

However, whenever you see bath water being thrown out, look for an associated baby.

In Android 8.0, Google added fingerprint gesture support. While relatively few devices have hardware support for this, it effectively turns the fingerprint sensor into a tiny trackpad. At present, you can detect swipes in the four cardinal directions (up, down, left, right), and you can take some action based upon this via a registered callback.

However, they put fingerprint gesture support in AccessibilityService. Hence, only apps that request the BIND_ACCESSIBILITY_SERVICE permission can find out about fingerprint gestures.

It is unclear why Google thinks that fingerprint gestures are primarily for users who need assistive technologies. After all, trackpads are fairly commonplace elsewhere, used by people with a wide range of abilities. Google even supports trackpads with Android apps on Chromebooks, without requiring the app to have an AccessibilityService.

Moreover, by putting fingerprint gestures into the accessibility APIs, not only would app developers need to fuss with an AccessibilityService, and not only would enabling that service trigger all sorts of privacy and security warnings to the user, but with the new Play Store policy, any app seeking fingerprint gestures needs to be for users with disabilities, period.

While the ban is aiming to defend users against unnecessary privacy and security challenges, there is nothing in today’s fingerprint gesture API that is sensitive, and it’s unclear what they could add in the future that would be sensitive. Even if the gestures somehow get integrated with actual fingerprint scans, there’s a separate API for fingerprint scans, not tied into accessibility.

So we get a new general-purpose feature, and courtesy of an engineering choice (where the API resides) and a policy choice (ban on unnecessary use of accessibility APIs), most developers cannot use that feature.

This brings me back to the TL;DR from the outset. Keep APIs with privacy and security ramifications separate from other APIs. Make it very obvious to all parties what portions of your API may put users at risk. Conversely, don’t attach normal APIs onto an API set that is sensitive just because it’s easier or, in the absence of those privacy and security ramifications, it might make sense. Bright lines help everybody understand what is and is not safe. And, in the future, should bans like this one be required, it is simpler to only affect those misusing the sensitive APIs if the sensitive APIs are clearly separated out from the remaining APIs.

In this case, given that accessibility APIs are going to have privacy and security ramifications indefinitely, IMHO the better approach would have been to have fingerprint gestures be somewhere else. For example, they could be just simple MotionEvent sources, not significantly different than how trackpads work elsewhere. Even if there are technical reasons for keeping fingerprint gestures out of the regular input framework, there could be a FingerprintGestureManager system service or some such that provided this ability, independent of the accessibility APIs. It’s not out of the question that this could be addressed in the timeframe of Android P (Peppermint? Pistachio? Pomegranate?), should Google choose to do so. Only time will tell if we can put this baby back into some bath water.

After all, you have to be very careful with some babies.