Google To Kill a Bunch of Useful Android Apps That Rely On Accessibility Services (androidpolice.com) 105
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
some of these are useful because android sucks (Score:2, Insightful)
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?
Re: (Score:2)
Huh, I thought Lauren was a woman's name.
Re: (Score:2)
Just like Ralph Lauren?!
What they're really doing... (Score:3, Insightful)
Re: (Score:2)
Re:What they're really doing... (Score:5, Insightful)
No, what they're really doing is making Android more secure.
After your emotions settle and your knee-jerk rant that seems equivalent to "Bwaaaaa they're taking away my favorite app! QQ", you might eventually realize that removing gaping security holes is a good thing.
Re: (Score:2)
But what they're doing in effect is saying "We're going to give you 30 days notice that apps purchased by millions of people will stop working until they're rewritten - and those rewrites will work on phones purchased recently-enough directly from Google and on the Samsung Galaxy S8 family running beta firmware."
Which phones have Oreo already? Not very many. Which existing phones are going to get it? Some of them, someday, maybe, but based on past performance fewer than you'd hope for.
I currently ha
Re: (Score:2)
"We're going to give you 30 days notice that apps purchased by millions of people will stop working until they're rewritten
Did you read this?
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.
They aren't going to stop working. You just won't get updates from the Play store anymore.
Re: (Score:2)
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?
Google isn't allowing it, you are when you install it. Google tells you about it and lets you decide.
Re:What they're really doing... (Score:5, Insightful)
I don't WANT a random app to be able to skirt around not having root access by claiming to need permissions for "Accessibiliy". Google is doing the right thing here, even if the approach may be a bit clumsy or ham-fisted. They were rightly panned a while back (right here on Slashdot) when shown how the Accessibility API could lead to security issues and they dismissed it as "not a bug / working as intended".
Android developers were using an API for purposes it was clearly never intended for. Only now it's understood that those APIs have security implications, so those "clever" hacks may no longer be viable. Google is now working to close those loopholes a bit by making sure app developers justify the use of those APIs, and the response is "Google Evil!" Perfect proof that you can twist *anything* to make it sound nefarious.
Re: (Score:3)
I don't WANT a random app to be able to skirt around not having root access by claiming to need permissions for "Accessibiliy".
If my experience with LastPass is indicative, you really have to go out of your way to grant an app this kind of access, the app can't make it happen on its own.
And if there isn't a woraround I may cancel my LastPass subscription, because most of what makes the mobile app useful is its ability to fill in usernames and passwords in other apps.
Re: (Score:2)
There is a proper API for doing this so you no longer need to use the accessibility workaround to get this working.
I believe Lastpass does use this api.
From what I have heard every application needs to be updated to specify that it is a username and password input field and your password manager application can be used to query this information.
Re: (Score:2)
I realized even if they pull the app from the Play store, I still have it, and they can still distribute it from their web site.
From what I have heard every application needs to be updated to specify that it is a username and password input field
So functionality would be hit or miss based on what third party developers are doing. Sounds like a major step backward.
Re: (Score:2)
Yes - the Autofill API:
https://blog.lastpass.com/2017... [lastpass.com]
Re: (Score:2)
It makes me think, "If what it was doing was so useful to so many people, then why wasn't there an API that was intended for that purpose?"
Then again, I have more intellectual curiosity than a slug.
Re: (Score:2)
Because a lot of times they're pushing the boundaries of what Google has even thought of doing.
For example, I wrote some software that uses accessibility to get the text of other apps and send it to Google translate so I can get in app translation of things not written in English. There's no API to do that.
Re: (Score:2)
Google aren't omniscient? WTF? Was that mentioned in the EULA?
But rather that's my point. I quite like your and I think it could be useful - but why isn't there a vanilla, non- accessibility, API to get the text?
It's like an os where there's no grep, but only an accessibility-grep.
Re: (Score:2)
Perfect proof that you can twist *anything* to make it sound nefarious.
This is slashdot, "$Company does $thing" is always met with anger, even, as the case here, when $Company does the opposite of $thing
Re: (Score:2)
I don't WANT a random app to be able to skirt around not having root access by claiming to need permissions for "Accessibiliy".
They can't. You would have to specifically go into the accessibility settings and move the slider to "on" for that app. Just don't do that. What I don't WANT is privacy nuts like you demanding a reduction in currently functionality that I happen to find extremely useful.
Re: (Score:2)
"Google isn't very friendly to people getting 1 million dollars from the google bank account. So much for "Don't be evil""
Re: (Score:2)
Google really isn't very friendly to users having control over their own device.
1. You can turn on "allow non-market apps" on any Android device and load whatever app you want.
2. If that's not enough, you can root any Android device, including Google's Pixel phones, and really do whatever you want.
So I don't get to write the program that I want (Score:1, Insightful)
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.
Re: (Score:2, Informative)
Can't do that any more unless you have permission from the higher-ups, I guess. So much for my computer, my rules.
That is correct.
Billions of people have voted against "my computer, my rules" by buying devices with phone-home level control given to someone else. Thus, the market provided what those people voted for with their dollars.
The personal computer era is over. What we have now is the spy-device and content-consumption-device era.
Re: (Score:3)
They're not stopping you doing anything with your own device. You can load any app you wish without the Play Store.
They're stopping apps using accessibility services for the wrong purpose. They've been criticised for the security issues related to these API's in the past.
No Android device stops you side-loading apps.
Re: (Score:1)
Some do. It depends on the manufacturer and if they hid those settings or not, especially once they set SELinux Strict. There are a few LG and Samsung models that I am well aware of that don't allow you to load any apps outside of either the official Play Store or in Samsung's case, their own market as well. Those particular models also have locked bootloaders and can't be rooted.
Re: (Score:1)
Re: (Score:3)
You are a stupid shit, so whether you try (and fail) to learn to program is immaterial.
Google isn't stopping you from using these APIs in your own apps on your own device.
Re: (Score:2)
Can't do that any more unless you have permission from the higher-ups, I guess. So much for my computer, my rules.
You can do anything you want with your device. Side load apps. Root it. Put it in a blender. Whatever you want.
What? (Score:4, Funny)
Re: (Score:2)
Google is going to kill a bunch of disabled people with Androids? What?
That was the plan - but, perhaps fortunately, Larry and Sergei lost interest and now it's been EOL'ed.
Re: (Score:2)
Isn't this OK because Android is not a walled gard (Score:2)
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?
Re: (Score:3)
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 s
Re: (Score:2)
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.
Re: (Score:2)
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/ [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.
It's unfortunate truth about accessibility feature (Score:5, Informative)
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.
Re:It's unfortunate truth about accessibility feat (Score:4, Insightful)
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.
Re: It's unfortunate truth about accessibility fea (Score:1)
Re: (Score:1)
I guess I misread the end of the first paragraph, and unreasonably tied it to the article.
Re: (Score:3)
>>>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
Re: (Score:2)
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.
Re: (Score:3)
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
Re: (Score:2)
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.
Re: (Score:3)
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...
Re: (Score:2)
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 f
Re: (Score:2)
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?
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
"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
Re: (Score:2)
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.
Re: (Score:2)
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.)
Re: (Score:2)
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.
Re: (Score:3)
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?
Re: (Score:2)
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.
Re: (Score:3)
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 l
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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
"Her" blog? (Score:2)
Re: (Score:2)
BeauHD got confused because Lauren didn't include his middle name, Francis.
The ability for an app to read another's data... (Score:1)
So "fix" the problem... (Score:2)
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.
Google's concern seems a bit hollow (Score:4, Interesting)
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.
Re: (Score:1)
" Why does just about every game in the app store "need" access to my contacts"
It doesn't, but the same privilege controls access to accounts on the device. This includes your google account to login to the Google Play Games in order to access achievements and leader-boards etc. Most games cope fine if you refuse the permission.
Blame Google for some of the questionable bundling decisions they made, but to be fair, they only bundled them because people kept complaining they had too many permissions.
Re: (Score:2)
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.
Because you granted it that access when you were shown the permissions at pre-install time and chose to install the app anyway?
Why does just about every game in the app store "need" access to my contacts, or permission to read my browser history?
Browser history is not a permission. It's private data to the browser app and no app can read another app's private data without being signed with the same cert.
I have only one Android device, a tablet. The first thing I did after getting it home was to root it and install CyanogenMod.
Great job. By rooting it you just opened the doors wide open for an app to literally do anything it wants including reading the memory space of other apps.
Re: (Score:2)
Google Always Said Other Use Cases Were Ok (Score:1)
Lastpass (Score:2)
Re: (Score:3)
Autofill API: https://blog.lastpass.com/2017... [lastpass.com]
Re: (Score:2)
Re: (Score:2)
By pure coincidence, Google has just integrated a LastPass competitor into Chrome. You should send all of your passwords to Google and stop being cautious about putting too much trust in any one vendor. #badsecurityadvice