Android 13’s new sideloading restriction of Accessibility APIs | Hacker News Reader

Android 13’s new sideloading restriction of Accessibility APIs

blog.esper.io

88 pointsjosephcsible117 comments

> Unfortunately, these functions are also incredibly useful for malicious apps [..] Google has already limited which apps on Google Play can use the Accessibility API, and in Android 13, they’re taking things one step further by heavily restricting API access for apps that the user has sideloaded from outside of an app store.

An API that is so limited that malicious apps cannot abuse it, is too limited to be useful for non-malicious apps. This is just boiling the frog to make sideloading entirely useless, so users need permission from Google for any app they wish to run.

The article explains how what you said is not correct.

You do NOT need Google's permission.

From the article: These restrictions are tied to a new permission in Android 13 called ACCESS_RESTRICTED_SETTINGS. This permission controls whether or not the user can enable an app’s accessibility service. When an app has been sideloaded using the non-session method, ACCESS_RESTRICTED_SETTINGS is first set to “deny”. After viewing the “restricted setting” dialog, ACCESS_RESTRICTED_SETTINGS is set to “ignore.” At this point, the user can go to the app info page for the app in question, tap the three-dot menu, and then tap “allow restricted settings” to unblock access to the accessibility service. The user will then be asked to authenticate themselves, and if they pass, ACCESS_RESTRICTED_SETTINGS will be set to “allow” for the app. The system does not tell the user they can do this, but this could change in future Android 13 builds.

Sounds like the accessibility apis are behind another settings screen now.

This is similar to allowing full network access for custom keyboards on iOS. You can't allow it via an easy prompt, you must navigate into settings and explicitly enable it

Same for always-on location access. I think this is the right way, users who intend to enable these things should really have to think about it and know what they are doing to allow an app that much access

Android's AccessibilityService API already requires the user to navigate into settings and explicitly enable the service for any given app.

The "restricted settings" dialog adds another explicit warning for users to acknowledge, which is IMO a good thing. The system currently doesn't tell the user how they can "allow restricted settings" for an app, though, which I think is because this feature is a WIP as of Beta 1. (The "allow restricted settings" button is in a different area of settings entirely from Settings --> Accessibility, and the dialog makes no mention of it/doesn't link to help material about the restriction. Definitely a WIP.)

Apple does this with a lot of their security interfaces where they block it with little explanation and then expect motivated users to figure it out by googling. Personally I find it offensive. Year over year we slowly lose control of our computers in the name of security. Where does it end? Our most personal invasive tools are not there to serve us anymore, they have other masters.

Per the article, alternative stores like F-Droid are not impacted. So no, Google's permission is not required. No frogs are being boiled, that's FUD. The actual specifics of the change seem about as carefully & considerately done as possible for what is a dangerous & nuanced situation.

> For your security, this setting is currently unavailable.

That's got to be one of the most Orwellian statements you can make.

My personal pet peeve is security dialogs that don't explain why permission was denied or how to get permission[0]. Some of the more recent Android lockdown error messages that Google has added to the OS seemed almost laser-focused on pissing me off.

Related: some of the scoped-storage changes they pushed through have error messages like "For your privacy, choose another folder" if you try to, say, grant an application access to the Downloads folder. This is stupid for two reasons:

1. There are legitimate reasons for wanting to do this, but no override for those cases

2. The message does not actually explain the privacy risk beyond saying that there is one

At least Apple tried to make a user-focused explanation for iOS's security policy. Google just says no in the lowest-effort way possible.

[0] Bonus points for UI design that actively hides actions you cannot do, purely to gaslight the user into thinking they don't exist.

I wish I could just mail Google a hundred dollar check and a note that says "please don't treat me like a goddamn mouth-breather" and get a permanent "I'm a big boy who wipes my own ass and everything" code for unlocking bootloader and giving root.

Sometimes I think it would hurt less to tear the bandage off quick and switch to iOS rather than watching Android slowly get beaten into the Apple mould.

This exists, just use Pixel?

I don't think Pixels let you keep all the functionality when you unlock the bootloader. Am I wrong?

You might be thinking of SafetyNet. I'm not sure if there are any reliable ways to get root without tripping SafetyNet, but last I knew you could - on a Pixel - flash a different ROM and then relock the bootloader, and you'd be fine. Things may have changed in the last few years though.

You still fail SafetyNet if you do that.

What apps are actually enforcing SafetyNet?

I wonder if would it be possible for something like εxodus to detect this when they scan an app. I'd love to see a SafetyNet flag in their scan reports.

Snapchat, Netflix, Pokemon Go, Super Mario Run, Android Pay, McDonald's, and most bank apps immediately come to mind.

Most of those make sense but why McDonalds?

None of them make sense. Remember that if it were really about security, then phones vulnerable to Dirty Pipe wouldn't pass, but they do. It's just about control.

"Coupon fraud"

It was always my banking apps that caused me problems.

You retain whatever functionality you want when you unlock the bootloader, or relock it after flashing.

Apps can choose to not service you if they detect modifications though.

You're being obtuse. An application choosing not to service you definitely counts as losing functionality.

When the hardware was painstakingly designed so that I can't tell those applications "no modifications here", that's very much a manufacturer and OS problem.

You're not wrong. Android Pay will stop working, and so will a bunch of third-party apps.

You can use Magisk + Zygisk/DenyList to get these apps working on a rooted device.

The trick Magisk modules can use to hide the unlocked bootloader only works as long as Google still supports legacy devices that didn't do hardware attestation of the bootloader being locked. As soon as enough time passes that they flip that switch on their end, that will totally break forever.

Also, even today, a few apps aren't fooled by that solution. Try the McDonald's app for example.

If Google decides to corner everyone it will only empower them to put energy into non-google ecosystems. It would be a big mistake IMHO for google to cut this off.

Pixels have their own issues. For example, Google at some point decided giving users HDMI-out was cannibalizing their Chromecast sales and haven't offered it on their phones since. They tend not to play nice with combo 3.5mm/charging adapters, and often have bizarre hardware and software issues that only crop up a few months after launch. Their new SoC is essentially a rebadged Exynos, and as a consequence it has trash GPU drivers that gimp gaming console emulation to an astonishing degree. Pixel users can't crop the screen to hide the camera cutout so I hope you enjoy watching videos with the world's biggest dead pixel on one side of the screen.

FWIW, I'm tearing the bandage right off for my next phone. If my phone won't treat me like a big boy, I might as well switch to iOS and get a marginally better user experience.

But at least with Android, the freedom is still there and is just quite hidden and inconvenient. With Apple you don't have it at all.

What about the user experience is better?

I'm weighing this option myself now, but honestly between an iOS device and a mid-tier Android phone, it's hard to tell the difference. Email / chat apps / web browsing is more or less the same.

Certainly the amount of telemetry collected by Android is markedly higher [0], but that's not so much of a UX difference.

[0] https://www.scss.tcd.ie/doug.leith/apple_google.pdf

I don't know how much of a difference there really is, but it surely cannot be worse than my current phone. It's budget (low-mid tier, and it shows), the camera is far from good, and my OEM's variant of Android has annoying additions that aren't allowed to be disabled. I'm hoping that iOS will be at least a slightly calmer experience, and that the better hardware will do its part to annoy me less even if I'm buying used.

This is an interesting take. I'd assume iOS could just be considered an OEM variant of a mobile OS. I switched to samsung, and its UX is pretty consistent.

> my OEM's variant of Android has annoying additions that aren't allowed to be disabled. I'm hoping that iOS will be at least a slightly calmer experience

Would android's additions still seem like annoyance if stock (and every variant) included those additions?

tbf, I think iOS is a pretty good OS (like most modern OSes).

> Would android's [OEM's] additions still seem like annoyance if stock (and every variant) included those additions?

100%. By additions I mean to say things like notifications that cannot be dismissed or hidden, or other aspects of this firmware that to my knowledge don't occur on any other ROM, but seemingly exist to annoy without providing a benefit.

There’s a night and day difference between iOS and even high end Android, starting with performance and consistency of the platform.

> Certainly the amount of telemetry collected by Android is markedly higher [0], but that's not so much of a UX difference.

Note that, per your linked source, the payload size is larger on Android, but iOS actually collects more types of data by default (like location, which iOS collects by default but Android doesn't)

Or you could use LineageOS or other roms that are unfettered by Google.

If you read the other comments in this thread, you'll notice that I mention lack of SafetyNet support as a huge problem.

For which apps? Like, very specifically?

I didn't think devs were dumb enough to still use this.

Banking apps, Google Pay, hell, even McDonald's. Anything which has payment integrated in it is fair game to have SafetyNet running. And it very much most likely not a dev-lead decision, but a manager-forced thing.

In addition to what the other comment mentioned, there's also at least Snapchat, Netflix, Super Mario Run, and Pokemon Go.

You're mad that you have to jump through a hoop to do something dangerous. So mad, that you're going to just... wrap yourself in bubble wrap & give up all control?

Switching to iOS is sending the literal opposite message that you want. It's telling the industry "I can't be trusted & I want no control over my devices."

Do note that the article describes multiple ways that non-Play Store apps may still be allowed to use these API's. For example, this change will not impact apps installed from an F-Droid repo.

I'm not sure what is gained by gating this on the API used though? Couldn't you get around this by having the user install something using the session API which then installs the malicious app that uses the a11y API - it might require convincing the user to click through another install, but I'm not sure how much of a barrier that actually is.

>Couldn't you get around this by having the user install something using the session API which then installs the malicious app that uses the a11y API - it might require convincing the user to click through another install, but I'm not sure how much of a barrier that actually is.

Just a note here, but the restriction isn't "chained". The malicious app using the a11y API itself only needs to be installed via an installer using the session-based API. So a "dropper" app implementing the session-based API could pull the APK for the malicious a11y using app from some source and then ask the user to install it. The malicious app's accessibility service could then be enabled.

Yes, this is a loophole, but if Google didn't do this, then you wouldn't be able to enable an app's accessibility service no matter where it was sourced from. And Google's already in hot water with the EU, so I don't think they want to get in trouble for hindering 3P app stores.

However, I still think this targeted approach is smart. A lot of apps that users use to download and sideload apps (browsers, mail clients, messaging apps) have no reason to go and implement the session-based installer API, so this restriction would add at least one more barrier to apps gaining a11y access.

> A lot of apps that users use to download and sideload apps (browsers, mail clients, messaging apps) have no reason to go and implement the session-based installer API

As the article notes even if those apps do want to use the session-based installer API for some reason, they can just flag that the APK came from either PACKAGE_SOURCE_LOCAL_FILE or PACKAGE_SOURCE_DOWNLOADED_FILE to trigger the same side-load protection behavior.

Which, yeah, I don't see why something like eg Firefox would be interested in bypassing this behavior.

For those who didn't read the article:

"Google confirmed to Esper that this restriction was designed to not affect apps installed from app stores, both preloaded (like Google Play) or sideloaded (like F-Droid). This is because the company does not want to restrict accessibility API access for all apps that are sideloaded — they just want to restrict access for apps that came from less legitimate sources."

Honest question

What keeps google from defining f-droid as a "less legitimate source"

I mean, nothing? Which means the fact that they specifically carved out an exception for all app repos implies that at least someone at Google is making a good faith effort here. It's still a pointless overreach there should at least be an easy setting for of course, but it seems as though they're trying to strike a balance between protecting the masses and giving power users power.

Right, in fact, when I was researching for this article, I thought that the fact that the restriction didn't apply when installing apps via the session-based installation API was a loophole/because it wasn't fully implemented in DP2.

I surmised that this loophole was intentional so as to not hamper third-party app stores from providing users with apps that use the AccessibilityService API, but I was only able to confirm my suspicion after contacting Google PR.

> It's still a pointless overreach there should at least be an easy setting for of course

That seems like a stretch. Why should it be easy to give any app full permission of your device? This is an extremely dangerous permission to give, well, anything. It should be possible (and it seems like it is), but why should it be easy?

And calling it a "pointless overreach" is some real sticking your head in the sand stuff. This isn't a fake threat. This abuse isn't theoretical, it's deployed in the wild. The article even provides multiple examples.

Can we as a hacker community say enough is enough and put our collective efforts into making something like PureOS a viable option for daily use?

PureOS currently suffers from a tragedy of the commons. I, like many others am afraid of investing a lot of my time into developing for it for fear that not many others will adopt it and my efforts will be wasted.

How can we build/market PureOS as a credible alternative for other app developers to start building on top of it?

*Edit It doesn't have to be PureOS - that was just an example. It could be Sailfish OS, or Plasma Mobile. We just have to pick one to create a self-sustaining ecosystem around.

> How can we build/market PureOS as a credible alternative for other app developers to start building on top of it?

Start by convincing paying customers that cyber security and/or their privacy are important.

One major hurdle is getting the existing app developers to stop intentionally hindering efforts to make their apps work through compatibility layers.

Can you expand more on this? Are they deliberately trying to detect compatibility layers?

Modern phones have chips that can do hardware attestation that they're running an OS that's been blessed by Google. A lot of apps, e.g., McDonald's and most banks, will refuse to run if this attestation fails.

Is this some kind of hardware based DRM?

It's called SafetyNet I think.

https://developer.android.com/training/safetynet/attestation

A lot of surprising apps use it because rooted devices are very commonly associated with fraud of various kinds e.g. credit card fraud.

Or so they say.

Integrating SafetyNet and maintaining that integration represents real work and therefore money. It's not like one line of code, it's a pretty complicated protocol and set of flows that require support in both client and server. If there was no actual problem to solve, why would organizations that are famously much more concerned with money than tech politics spend their money in that way? I really doubt McDonalds cares about the freedom to modify phones one way or the other.

Does PureOS solve this accessibility vs. malware tradeoff?

This question feels like asking whether DRM-free platforms like GOG solve the freedom vs. piracy tradeoff.

By attracting only geek users that know better than saying yes to allowing a random shady flashlight app to take full control over their device.

It's only at the beginning of the development. It will, if the community makes it.

You can't. Microsoft, Samsung, Huawei- they all tried.

Understandably because nobody wants more work.

GrapheneOS.org

Or we don't slave away to maintain another community project and instead impose regulations on these companies to work for us.

If you are a teenage hacker with nothing better to do, sure, spend your time hacking a new OS to run on closed ecosystems. If you are an adult with work and responsibilities, take political action.

There is no such thing as side-loading. Installing applications is the default, locked-in walled gardens are the thing we need a term for. e-Prison?

Since it's Apple's fav thing, I recommend iPrison.

I recommend "app prison" or a similarly un-nerdy term to get some traction. e-Prison sounds like something the FSF would come up with.

@dang or other moderators, could you please kindly fix the headline? The correct headline is:

> Android 13’s new sideloading restriction makes it harder for malware to abuse Accessibility APIs

Seems a lot less inflammatory.

edited for politeness

That's too long, or I would have submitted it like that.

Tracking can be much more harmful so when will Google make app developers, including themselves, hop thru this many hoops to protect users?

Rooting becomes a no brainer - message sent from rooted lineageos poco x3 pro

Help, I can't access my banking app!

- sent from every device with SafetyNet invalidated.

I'm not trying to be sarcastic, just pointing out the reality of the situation and the reason why I didn't root or mod my own phone.

You can install 3rd party roms but skip the rooting part to not mess with SafetyNet.

That still breaks SafetyNet, because it checks if the bootloader is unlocked, which it has to be to install a custom ROM.

The only time an Android "upgrade" has given me a better experience was when I updated a tablet from Android 3 to Android 4. Every other time it's been worse performance and broken workflows.

I understand the broken workflows thing. But "worse performance" actually sounds a little bit impressive to me (relatively speaking), because it implies you've had multiple Android devices actually get major version upgrades, rather than being abandoned and forcing you to buy a new device to get a newer OS.

Some devices are truly loved by the community and kept alive by people tirelessly adding support for those devices in lineageos. For example, galaxy s4 [1], a phone released on 2013 (Android 4.2 jelly bean), is still supported by lineageos 18 (android 11).

[1] https://wiki.lineageos.org/devices/jflteatt/

But remember that you still don't get security updates to the OEM's proprietary drivers with custom ROMs.

I'd be tempted to like Android 4 but I think that's when they got rid of the framebuffer requirement for kernels so it meant you had to use Android for graphics and couldn't just replace the userspace with eg debian anymore.

EDIT: I've probably used up my quota so here's my reply: Userspace only cares about CPU arc. You can grab a debian rootfs and run it on a kindle/android/rasbpi etc. without even having to recompile things. The kernel however needs drivers and with modern Android many of them have to be rewritten. Replacing the kernel is a development exercise while replacing the userspace is mostly a matter of just installing the right software.

If you're replacing the whole userspace, why not just replace the kernel too at that point?

Hardware support? Software compatibility?

God, Android 13 is fugly. It's as if they've taken the worst of iOS and the worst of MIUI and merged it.

...did anyone here read the actual article?

Unless I missed something, the article basically says what the headline says. There's some nuance, but "you can currently work around this by jumping through some major hoops" doesn't really change much IMO.

Absolutely capital dogshit move, a direct slice at the jugular for user freedoms, for letting people do computing in their terms.

The presence of bad actors keeps being used as ammunition to destory possibility, to end softness, to make computing hard & inflexible, and it's the same genetic makeup as the constant cowtowing to fear that let's 'think of the children' be the deciding & only opinion policy gets passed with.

Loathsome detestable & massive setback, colossal unwinding of Android's spiritual advantage versus The Loyal Opposition Apple. If both platforms collapse into anti-choice, what happens to Apple's defense that it's users can go elsewhere? These shackles we permit to be set upon us, this prohibition of sideloading, the anti-generalization of computing can only be defended against by principled stances. For eroding possibility is forever to the megacorporate bottom line's profit. What a degrading trashfire move, Google, responding to the bad at such vast setback & penalty for the very very very good. Unlocking & exposing applications in new & amazing fashions is one of the highest & most virtuous goods, one of the best things we can do- reenable some unknown, go further- and this move speaks of a desire to embrace old stasist ossifying & cold death, to make us all rot forever with whatver is or was.

Nice rant. But the headline leaves out a lot of detail that is in the article, which negates your rant.

"The feature still exists, behind a dark pattern of undiscoverability" really isn't as good of an excuse as you seem to think it is.

They didn't remove the feature. It's simply been moved to the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying "Beware of the Leopard".

I disagree. The very presence of these headlines indicates exactly what both the parent and myself are afraid of: that Android is losing uselessness for power users. The rant is far from being untrue.

That comment was one rollercoaster of a ride. Very poetic, in a good way. Android was my favourite smartphone OS since it championed user freedom. Now that this freedom is reduced, there isn't much holding me there vs, for example, iOS.

As bad as moves like this are for freedom, even if Google did 20 more like it, Android would still be much freer than iOS.

I'm not so sure. Rooting a phone or flashing a custom firmware breaks Safety net, which means a good portion of apps that I find important will not run on my phone. An unrooted/unmodded device can be really annoying to use depending on what the manufacturer put in the ROM.

I can't really think of a single thing beyond "sideloading" (what a repulsive word) apps and maybe filesystem/SD card access that Android has as an advantage over iOS, while the list of disadvantages keeps getting longer.

I agree that's a big problem, but it's still less bad than iOS where you just can't flash a custom firmware. And sideloading is a really, really big thing.

While I can flash it, it's very unlikely that I actually will due to the invalidation of the SafetyNet status that I mentioned. If I can't make use of this feature without losing apps I care about, then I might as well treat the phone as if it never came with that feature in the first place.

As for lack of sideloading, we'll see. I heavily rely on NewPipe, but maybe there's another way to scratch that itch.

The last time I flashed lineageos, safetynet status was still green unless I rooted the devices. Is this changed? I usually skip rooting the device when installing custom rom because I don't have any real need for it.

This is changed on all but the oldest devices.

All mobile OSes are dogshit.

PalmOS/webos forever! ;)

I never actually used it. But I like the idea. And I believe the web platform is a good existential hedge against the undying forever turning-to-crap-iness that so widely defines the trend of everything else. For now web standards still have a lot of good geeks advancing good moral causes and capabilities-- amid some less than excellent causes, yes, but even these make their way through gauntlets of review, through committees.

Ionic say hello. The web is so far ahead it's humiliating, e.g. PDF.js is the only PDF renderer to have a standard acessibility tree.

Maybe, but simultaneously its performance on any slightly more complex/heavy-weight PDF file is still noticeably inferior.

I find the reverse to be so true! I mean i have not tested it heavily on 100+ pages so maybe for that but WOW for a regular sized scientific paper the difference in both smooth scrolling and text selection accuracy and speed is insane compared to the default chrome native pdf renderer. The difference is instantly noticeable (although me being on a 4K screen might help) that is why I use the Chrome PDF.js extension to make it my default reader.

Interesting. For medium or heavy-weight CAD plans with loads of vector graphics the browser based PDF renderers (I tried both Firefox and Edge) are definitively slower for me.

1) PDF.js can be faster on chrome than on firefox (needs the extension) 2) the chrome extension expose in settings a webGL renderer, which can be much faster for specific kinds of PDFs

No. Try opening sea charts (from NOAA) in pdf.js. It just doesn't work at all. Meanwhile mupdf handles them fine like any other pdf.

Can you share me a link? I searched on NOAA website and didn't knew where to look at. BTW I deeply recommend you the yt channel DeepseaOddities https://youtu.be/EkVY2EvFSgo BTW I just tried muPDF and the rendering is blurry on my 4K screen, unfortunately

> And I believe the web platform is a good existential hedge against the undying forever turning-to-crap-iness that so widely defines the trend of everything else.

I'm sorry to say, but my view is the exact opposite. I can place nearly all the blame for the current state of the software ecosystem on overuse of web technologies and JavaScript.

Make an actual claim please. You've made no case, not explained why you think so very poorly, offered nothing that could be argued with or contested. This isnt useful or contributive.

My claims:

- the rise of Electron means that:

1. a lot of native applications got killed off

2. those that remain have fewer features (native applications generally tended to be feature-rich). For example the web version of Outlook is nowhere near as feature-ful as the true native version for Windows.

3. Electron apps have worse UX due to much slower response times to every single click (which is both perceptible and infuriating, if you are one of the people that can see it), consume much more RAM (no, RAM is not cheap - maybe for you it is, but is it cheap for the end user?), and do not use native controls a lot of the time. The former two points can be verified by loading Microsoft Teams.

4. Even if the user has enough RAM for an Electron application, they may not have enough RAM for five. Lighter-weight alternatives aren't always available, and sometimes you just have to run that many side by side if required by your work.

- due to this, many machines that could have otherwise been useful for a few more years (anything with <=4 GB of RAM in my experience, YMMV) became e-waste prematurely because of the accelerated obsolescence, which not only imposes unfair cost on the consumer, but is also bad for the planet.

- the JavaScript ecosystem largely relies on NPM for dependencies. NPM is very far from the level of maturity achieved by comparable ecosystems for other programming languages. This means that somewhere down in your dependency chain, your application relies on something ridiculous like left-pad. This results in a technically inferior product, and more pragmatically speaking, introduces many more opportunities for third parties to break your dependency chain (intentionally or not), or to slip in extra code (I think it was node-gyp, a common dependency, that selectively ran in destructive mode in case the current machine's geoip was Russian or Belarusian).

A lot of the points I raised about Electron apply to JavaScript as well.

TL;DR: the JavaScript ecosystem is not very conducive to good (stable and performant) engineering, short of heroic efforts like those undertaken by the VS Code team. Most teams don't actually care as much, so the resultant Electron applications are slow and unnecessarily huge. The result is a worse user experience.

Electron only became popular because of the extremely developer hostile nature of mobile OSes.

That's pretty obviously untrue since Electron doesn't work on any mobile OS. It exclusively targets desktop OSes, specifically Windows, MacOS, and Linux.

Places where things like QT already worked great at a tiny fraction of the compute resources required.

Unironically agreed. I haven't liked a mobile OS since circa Android 5.

Reply on news.ycombinator.com