Ataul Munim
Sep 12, 2016 · 3 min read

A few weeks ago Android Weekly promoted a post highlighting a security issue with the Android accessibility framework. While I agree with part of it, I find the solution offered is not adequate and is actively harmful to users. In this response, I’ll explain why I disagree with the prescribed action.

There is an app (popular in India) that behaves as an Android Accessibility Service. It does this to gain the ability to read the content of the on-screen app to augment its own service.

Image for post
Image for post
Screenshot of the Voodoo Shopping Assistant app from Google Play

The post from AW raises a fair point — isn’t this dangerous? Accessibility services on Android have access to everything you type and all the forms on your screen.

Android warns the user of this when they enable the service:

Image for post
Image for post
Screenshot of warning dialog when enabling TalkBack. It lists all of TalkBack’s permissions including “observe text you type”

It highlights that personal data can be observed, including credit card numbers and passwords.

Third-party keyboards can also access this information, and Android warns users here too at the point of enabling:

Image for post
Image for post
Screenshot of warning dialog shown by Android when enabling third-party keyboards like SwiftKey

These keyboards are more common than accessibility services — SwiftKey has 50–100M downloads, compared to Voodoo’s 0.1–0.5M.

The post encourages app developers to mark sensitive fields with `View.IMPORTANT_FOR_ACCESSIBILITY_NO`, in order to protect the user from giving accessibility services access to things like login forms.

It’s incorrect that this will make the field invisible to accessibility services. Apps like Voodoo will be told they shouldn’t read that field, but it does nothing to stop them reading it. What does this mean? Valid services like TalkBack, Spiel or Switch Access will respect this property, making the field invisible to the user. Malicious services will ignore it.

TalkBack, for example, is an Android accessibility service designed to help visually impaired users interact with their devices. It acts as a screenreader (reads screen content aloud) and an input mechanism (uses gestures to perform common actions with less touch precision, like clicking and navigating through lists).

If the password field is marked as “not important”, then TalkBack cannot convey its existence to the user and, consequently, the user cannot login.

This action is actively harmful and doesn’t seem to help in the majority of cases, unless I missed something and the post also advocates for creating your own on-screen keyboard.

Personally, I wouldn’t worry. If you are worried, I would remind the user on screens where they are about to enter sensitive information.

You can do this with a dialog that is shown when the app detects that an accessibility service is running, and that blocks input until there is acknowledgement:

AccessibilityManager accessibilityManager = (AccessibilityManager) context.getSystemService(Context.ACCESSIBILITY_SERVICE);
boolean showDialog = accessibilityManager.isEnabled();

Novoda would probably even accept a pull request to add this check as another API.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store