Slashdot Mirror
Google To Kill a Bunch of Useful Android Apps That Rely On Accessibility Services (androidpolice.com)
Slashdot reader Lauren Weinstein writes from a blog: My inbox has been filling today with questions regarding Google's new warning to Android application developers that they will no longer be able to access Android accessibility service functions in their apps, unless they can demonstrate that those functions are specifically being used to help users with "disabilities" (a term not defined by Google in the warning). Beyond the overall vagueness when it comes to what is meant by disabilities, this entire approach by Google seems utterly wrongheaded and misguided. "While the intended purpose is for developers to create apps for users with disabilities, the API is often used for other functionality (to overlay content, fill in text fields, etc.)," reports Android Police. "LastPass, Universal Copy, Clipboard Actions, Cerberus, Signal Spy, Tasker, and Network Monitor Mini are just a few examples of applications heavily using this API." It's likely Google is cracking down on apps that use Accessibility Services due to the security risks they pose. "Once granted the right permissions, the API can be used to read data from other apps," reports Android Police.
The developer of BatterySaver received the following message from Google:
We're contacting you because your app, BatterySaver System Shortcut, with package name com.floriandraschbacher.batterysaver.free is requesting the 'android.permission.BIND_ACCESSIBILITY_SERVICE.' Apps requesting accessibility services should only be used to help users with disabilities use Android devices and apps. Your app must comply with our Permissions policy and the Prominent Disclosure requirements of our User Data policy.
Action required: If you aren't already doing so, 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. Apps that fail to meet this requirement within 30 days may be removed from Google Play. Alternatively, you can remove any requests for accessibility services within your app. You can also choose to unpublish your app.
Alternatively, you can choose to unpublish the app. All violations are tracked. Serious or repeated violations of any nature will result in the termination of your developer account, and investigation and possible termination of related Google accounts.
If you've reviewed the policy and feel we may have been in error, please reach out to our policy support team. One of my colleagues will get back to you within 2 business days.
Regards,
The Google Play Review Team
The developer of BatterySaver received the following message from Google:
We're contacting you because your app, BatterySaver System Shortcut, with package name com.floriandraschbacher.batterysaver.free is requesting the 'android.permission.BIND_ACCESSIBILITY_SERVICE.' Apps requesting accessibility services should only be used to help users with disabilities use Android devices and apps. Your app must comply with our Permissions policy and the Prominent Disclosure requirements of our User Data policy.
Action required: If you aren't already doing so, 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. Apps that fail to meet this requirement within 30 days may be removed from Google Play. Alternatively, you can remove any requests for accessibility services within your app. You can also choose to unpublish your app.
Alternatively, you can choose to unpublish the app. All violations are tracked. Serious or repeated violations of any nature will result in the termination of your developer account, and investigation and possible termination of related Google accounts.
If you've reviewed the policy and feel we may have been in error, please reach out to our policy support team. One of my colleagues will get back to you within 2 business days.
Regards,
The Google Play Review Team
some of these cover gaps in android and make it suck less
when my devices are sluggish and quirky greenify is great
how about google fixes android suck before breaking viable work-arounds?
android is a dumpster fire.
Is cracking down on apps that use accessibility services as a way of getting around not having root access. Google really isn't very friendly to users having control over their own device. So much for "Don't be evil".
So I don't get to write the program that I want even though the functionality is there.
Remind me again why it's worth learning to write programs. I always thought it was so I could create the functionality that I wanted to create; something is missing here that I want or can use so I'll make a program to fill in that gap.
Can't do that any more unless you have permission from the higher-ups, I guess. So much for my computer, my rules.
If you're a zombie and you know it, bite your friend!
Google is going to kill a bunch of disabled people with Androids? What?
So this is a serious question, since people can side load android apps more easily than jailbreaking an iPhone, could not some of these apps realistically just offer apps outside the Play store? I know it would cut down a great deal on people willing to bother but at least it's still a path.
Or would Google frown on this and start shutting down developer accounts?
"There is more worth loving than we have strength to love." - Brian Jay Stanley
As someone who is disabled and depending on speech recognition, I've often wondered how to reconcile the need for security with accessibility systems need for deep access into applications. I think the industry is taking the approach of telling disabled people "sucks to be you, go make a living selling pencils on the street corner".
Deep access is needed because the information present in a GUI is insufficient for building grammars speech recognition environments. But even if we could live with the GUI, accessibility needs are wide open holes in system security. When you're disabled, you need to automate common tasks and you need to make decisions about state of the application in order to do the right thing. For example, if I want to download bank statements from the bank, I should be able to automate and automate naming the given PDF the right name but I can't. However giving me that capability would transfer enormous power not just to me but to any attacker.
It's time to start spending all of those tech billions to sending disabled people to that happy farm in the country where your parents sent your dog when it got old. I'm all for this cause I'm tired of arguing with developers about why accessibility is a needed and important part of giving a disabled person independent and satisfying life.
Google seems to be saying "tell us how your app helps access" not sucks to be you.
They're making a small hurdle to have apps distributed in the official store, they don't seem to be eliminating the API or blocking apps that actually are for access.
Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
>>>I've often wondered how to reconcile the need for security with accessibility systems need for deep access into applications
The easiest way that springs to mind is to NOT make the accessibility features of the OS available unless the user specifically asks for them. I'm temporarily able-bodied, so I don't need such features - and preventing every app under the sun from using them makes for a more secure system. If 75% of the systems don't support accessibility, the amount of malware targeting accessibility will be vanishingly small.
That said, having accessibility "Off" be default is no excuse for app developers to not support it. Yes, you can write an app and not support accessibility - but it's an anti-social thing to do.
And the worms ate into his brain.
It's a path to get it, but for the most part only existing fans of the apps are going to use them. Depending on the app, there may be other play services that may require being listed in the Play Store (such as advertising hooks), so this could eat into their income and/or cause the app to end up using less trustworthy advertising networks.
Additionally, installing apps from random places is just not as secure. It's one of the primary ways Windows and even Android ends up with malware.
Unlikely Google would shut down any accounts over it. Besides, if the developer is only doing one main thing, there is no developer account needed. That's only to be listed in the store.
I'm so confused.
.. especially in a permission per app restricted environment, is dangerous. Root your device and do what you will, but this is a secure move for the public facing store where the general layman won't know what completely entails 'accessibility' permissions.
I don't read AC
it's not yours... it's OURS
It's also a problem for accessibility laws.
On iOS, we use accessibility identifiers as UI identifiers for the UI automated tests that run as part of every build upon a commit. Same thing happens for our Android version.
I'm unimpressed at Google trying to weed out "casual" users of their accessibility in order to minimize a security issue that's their problem. Even if an app has marginal support for accessibility, it's still a good thing as opposed to not having accessibility altogether.
Add some bullshit accessibility feature to your app and then you have a reason to use the API. And you can use it to your devious heart's content. Better yet, do the disabled people in the world a service and add decent accessibility features to your app. Then you'd be doing good and have earned the moral (if not legal) right to abuse (at least in its corporate owners' eyes) the API.
That is all.
Perhaps I'd find this sudden concern about security a bit more believable if Google hadn't allowed every app that's come down the pipe since the Stone Age basically to rape whatever device it's installed on. Why does just about every game in the app store "need" access to my contacts, or permission to read my browser history?
I have only one Android device, a tablet. The first thing I did after getting it home was to root it and install CyanogenMod.
I wish I could believe this move by Google meant they intended to reexamine a corporate mindset apparently dedicated to the utter destruction of any vestige of privacy among those using its ubiquitous services.
Sadly, I can harbour no such illusions. That's unfortunate, because this admittedly security-related measure will hurt many people who don't regard themselves as "disabled", but who need easy access to the services affected.
I've calculated my velocity with such exquisite precision that I have no idea where I am.
According to the US EEOC, a disability is any medical condition that interferes with a major life function. The intent is for a broad interpretation not one that has to be litigated in the courts. The intent is to provide accommodations for individuals that need them. Individuals are not required to prove their disability. I can see this as a class action against Google composed of individuals that are being discriminated against due to their disability. Basis = disability. Issue = prevention of necessary accommodations. Resolution = provide accommodations.
See subject & what you said (lol) - picture that!
* I ordinarily don't "go for" posts like yours, but "ya got me"!
APK
P.S.=> Very funny JoeDuncan... apk
As someone who is disabled...
I'm also disabled, but I don't need speech recognition. I'm partially deaf, with tinnitus, so what I often need is more text, less voice. And, I'm diabetic, which is considered a disability, but I don't need any special technology for that. The point here is, there are many kinds of disability, and different people need different forms of assistance to work around them. There's no way this can fit into a One Size Fits All package, although I'd not be at all surprised to learn that that's exactly what Google is trying to do.
Good, inexpensive web hosting
I'm unimpressed at Google trying to weed out "casual" users of their accessibility in order to minimize a security issue that's their problem.
How is the security issue 'their problem' ?
Its a catch-22. If I give a screen-reader app access to read my screen when using other apps, then it can read the text my screen... even when I'm looking at my saved passwords in my password app.
If you write an app that asks for accessibility permissions, how do i know it isn't scraping my screen and sending my passwords to your mothership?
You can't 'fix' that. That's the nature of the accessibility functionality. The only thing that is reasonable is what they are doing... looking at the apps that are asking for accessibility permission and verifying that they need it.
At least that way I can't write a flashlight / fart app... give it accessibility support, and rip off your passwords. I'm going to at least have to come up with some actual utility for the accessibility API to justify using those APIs.
If anything, it needs to go further, more granular access to the API, and deeper audits of any programs using them.
could not some of these apps realistically just offer apps outside the Play store?
Yes. There are numerous apps that do exactly this.
My personal opinion is that, given that app stores are designed to cater to people who want to treat their phones as an "appliance" rather than a computer, it makes sense to lock them down tightly enough so that my grandma won't get into trouble if she stays with the app store.
The rest of us, who use our phones as computers, can get our apps outside of that walled garden.
I really can't see any other way to make the phones secure enough for the clueless and still powerful enough for the clueful.
The easiest way that springs to mind is to NOT make the accessibility features of the OS available unless the user specifically asks for them.
That's already how it is. You have to go into settings and flip a switch, which then prompts a scary warning about how the app can pwn your device, which you then have to agree to. Only after all that will the app have these features available. Apparently that is not safe enough?
Every android user has a mental disability, otherwise they won't be using android in the first place.
And homeless people make *great* wifi hotspots. Fuck Google.
Why does a screen reader for the blind needs network access? Does it take a screenshot and send it to India where someone reads it and sends the audio back to your app?
So maybe the fix is to prohibit an app from having both network access and accessibility permissions. It can have one or the other but not both.
Any sufficiently unpopular but cohesive argument is indistinguishable from trolling.
Can't just @GooglePlayDev add special section for usage of Accessibility Service to approve a feature inside apps and then give a sign to eligible apps!? (Like #AndroidWear)
Why does a screen reader for the blind needs network access?
Because ....
- it uses a cloud service to assist with text to speech.
- it uses a cloud service to sync your settings and preferences between other instances of the screen reader you have on other devices.
- it has a remote assist feature you can invoke to manually send a screenshot to our support team and a human will verify / correct the machine interpretation -- super handy if the screenreader is reading out gibberish and you need help!
- I could go on...
1. Do the text to speech directly on the pocket computer rather than relying on a service on the other side of the Internet that won't be available on an offline tablet anyway. Pocket computers nowadays are over a thousand times faster than the 8-bit MOS 6502 clocked at 1.02 MHz on which SAM (Software Automatic Mouth) ran.
2. Sync the settings only when the settings activity is frontmost. Open no sockets when the settings activity is not frontmost.
3. Seek Google's permission to whitelist the "remote assist feature" for your Google Play Store publishing account.
What are you talking about? He never said anything like that
I used some accessibility app to disable the app switcheroo button because I kept touching it while gaming. Fucking alphabet SJW commie cunts.
I guess I misread the end of the first paragraph, and unreasonably tied it to the article.
Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
Thank you Google, for helping Samsung prevent us from remapping the Bixby button to something useful.
Sorry, just to clarify - I meant he never said anything like that except for the part where he specifically did say that. There, happy now, Mr. Pedantic?
Since at least when I started working on AutoInput Google have said that accessibility services could be used for other situations other than to help disabled people. Even now this page lists other use cases: https://developer.android.com/... You can see how there's a note there: Note: Your app should use platform-level accessibility services only for the purpose of helping users with disabilities interact with your app. This note was only added very recently. Check out this version of the page from July: https://web.archive.org/web/20... This means that until a few months ago developers were using these APIs exactly how they were meant to be used: in a way that helps people use their devices in situations that they can't physically touch or otherwise handle their Android device.
You don't need it yet. A common side effect is eye damage but you knew that, I hope.
And what's a necessity to the disabled can still be a great convenience for the able-bodied. Wheelchair ramps is great if you're carting a baby around.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Why should I have to be disabled to be able to automate a thing like that? Downloading the bank statement and naming it right is an annoyingly long process, not least of which is because the bank's server doesn't suggest a name ending with ".pdf" so the save file dialog shows existing files that end in ".aspx' instead.
Other things like screen readers or screen magnifiers are useful for people with otherwise fine sight under some circumstances.
So basically, the things that are necessary for some disabled people to use the service are also often useful for able bodied people. Those developers you're arguing with should realize that they can make a better experience for EVERYONE by making their app/website/whatever more accessible.
"Save the whales, feed the hungry, free the mallocs" -- author unknown
It's not safe enough because the average Android user blindly clicks through even the scary warnings after years of too many apps having to work round missing APIs. If nothing else Google will get a clearer idea what's still missing in their API.
As an app developer I don't hurry to switch working functionality to use newer APIs, we need a kick sometimes to do it. Especially when we've used hacky tricks to get stuff done.
1. Do the text to speech directly on the pocket computer rather than relying on a service on the other side of the Internet that won't be available on an offline tablet anyway. Pocket computers nowadays are over a thousand times faster than the 8-bit MOS 6502 clocked at 1.02 MHz on which SAM (Software Automatic Mouth) ran. 2. Sync the settings only when the settings activity is frontmost. Open no sockets when the settings activity is not frontmost. 3. Seek Google's permission to whitelist the "remote assist feature" for your Google Play Store publishing account.
Wouldn't #2 still require that the app needs network access?
Why does a screen reader for the blind needs network access?
Because it's not screen readers for the blind they are banning.
It's all the crap that promises to do one thing, which may need network permission, but even though it's NOT a screen reader, it still needs access to the screen reader API.
Wouldn't [sync of an accessibility app's settings between devices while the sync activity is in foreground] still require that the app needs network access?
It requires network access for the separately downloaded sync app, not for the TTS app with which it communicates through same-publisher IPC. Those who don't want sync can choose not to download the optional sync feature.
They can- but they lose the easiest way of advertising and promoting their apps. Getting people to do it from the playstore is hard enough, getting people to do it from a website is an order of magnitude harder.
I still have more fans than freaks. WTF is wrong with you people?
Yeah- the number of people who would actually understand and download two apps to get the full features of one app is approximately 0. I'd be confused and not trust it as a programmer- forget nontech savy
I still have more fans than freaks. WTF is wrong with you people?
"1. Do the text to speech directly on the pocket computer rather than relying on a service on the other side of the Internet that won't be available on an offline tablet anyway. Pocket computers nowadays are over a thousand times faster than the 8-bit MOS 6502 clocked at 1.02 MHz on which SAM (Software Automatic Mouth) ran."
Sure I could do it directly on the device, and will even fall back to that, but I can do it better in the cloud.
"2. Sync the settings only when the settings activity is frontmost. Open no sockets when the settings activity is not frontmost."
My malicious app just stores the data it wants to send out and it goes out 'when the settings activity is frontmost'. I don't know why you thought this was a solution.
"3. Seek Google's permission to whitelist the "remote assist feature" for your Google Play Store publishing account."
Precisely. This is basically what google has done, you need to ask google to whitelist your use of the accessibility feature. You have to justify it, and it still comes down to trust. My app could still be malicious.
But at least I have to put in the work of making a useful TTS app to get whitelisted. I can't just clone some popular game, and include some accessibility malware to rip off your passwords, without so much as a by-your-leave.
Its not fool proof... but its progress.
Now that Google has their own version of Lastpass of course they would want to gimp Lastpass...
It uses the disability system. FUCK!
My malicious app just stores the data it wants to send out and it goes out 'when the settings activity is frontmost'. I don't know why you thought this was a solution.
You have a point. Let me revise my mitigation:
Do not obtain assistive apps from Google Play Store. Instead, obtain them from F-Droid, which rebuilds each package from source code before making it available to users, and audit the source code that F-Droid built.
Heh, ok. I like f-droid too, and I agree this is the best technical solution.
I'm not sure its a practical solution, in that, if you are blind and need a text reader, limiting yourself to f-droid may not really be a viable solution.
(And of course there is the catch-22 that a blind person can't audit the source without first obtaining a good text reader. But hopefully we can rely on some sighted friends or security researchers.)
You don't need it yet. A common side effect is eye damage but you knew that, I hope.
Yes, I had a friend who had that happen. I've always taken care of myself, and after fifteen years, there's no retinopathy or neuropathy, although I have had cataracts removed.
Good, inexpensive web hosting
So this is a serious question, since people can side load android apps more easily than jailbreaking an iPhone, could not some of these apps realistically just offer apps outside the Play store? I know it would cut down a great deal on people willing to bother but at least it's still a path.
Yes, and you can even sideload a different app store such as F-Droid, same as how the Amazon app store works.
https://f-droid.org/
Or would Google frown on this and start shutting down developer accounts?
There are thousands of developers that work outside of the Play store. I think we would have heard about it.
I'm unimpressed at Google trying to weed out "casual" users of their accessibility in order to minimize a security issue that's their problem. Even if an app has marginal support for accessibility, it's still a good thing as opposed to not having accessibility altogether.
Um, what? They are weeding out uses of accessibility APIs for non-accessibility purposes. If your app has a legitimate use for accessibility all that's required is a description of that sent to Google.