, , and

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 ’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 .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.


Need help with Android app development? AndGlobe lists dozens of support sites, in a range of languages!


  





Source link

LEAVE A REPLY

Please enter your comment!
Please enter your name here