Android’s Accessibility API is an incredibly powerful tool intended for developers to build apps for users with disabilities. The API lets apps read the contents of the screen and perform inputs on behalf of the user, which are essential functions for screen readers and alternative input systems. Unfortunately, these functions are also incredibly useful for malicious apps that want to steal data from users, which is why Google has been cracking down on which apps are allowed to use the Accessibility API. 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.
And so, step by step, Google locks down more and more of Android. Some of the most fascinating and unique applications use the Accessiblity APIs, and making it harder for them to do their thing will have a chilling effect on the wild innovation we see in the Android world. For now, this restriction only applies to applications sideloaded outside of application stores (e.g, applications installed through F-Droid are not affected), but I have my doubt slippery slope is suddenly going to even out at this specific point.
After all, we must be protected against ourselves at all costs.
I’m left wondering where this leaves users of alternative android devices like lineageos. I’m forced to sideload applications quite a lot. I don’t have (nor want) google play services on my device. While I use and like f-droid, the vast majority of applications aren’t available there and most have to be downloaded from mirrors. So these restrictions are worrisome.
From the article…
Even f-droid itself gets sideloaded. You use the browser to download and install an alt-store like f-droid, which will be marked as restricted, but f-droid itself can download and install applications that aren’t restricted? Do I have this right? How does this make any security sense?
Also, if packages installed via “session package installation API” are not artificially restricted as reported, then what’s stopping all sideloading applications from switching to that API to perform all sideloading in the future? And if they do then what exactly is the security benefit compared to how things worked before? Do we have an android dev who can clarify this?
Alfman,
Not an Android dev, but I can guess alternative Android devices are unlikely to be affected. This is open source after all, and they can choose not to merge these parts onto their distribution.
On a more practical note, I had ran into a similar issue on my Samsung phone. When I used several apps to change the default assistant button, and the Lastpass deeper integration (I think it also used the accessibility API), the Knox system locked out many of my apps (including fitness trackers). Fortunately it was a soft lock, and a full factory reset fixed it.
It was very frustrating, since I was configuring my phone, using the apps I chose, but it would lock me out of my own data.
sukru,
Idealistically I’d agree. However while AOSP is open source, we often don’t have the ARM drivers to make it useful, so typically we’re stuck on the same kernels that the manufacturer includes. LineageOS gets the same versions, has the same features, has the same EOL, same bugs, same limitations, and so on… For example, when google intentionally broke wifi scanning apps on android, that broke on corresponding lineageos images too. When google backtracked and provided an option to reenable it, everyone including lineageOS users had to wait for manufactures to provide updates (it took 2 years before my device would get the update). The improvements and bug fixes cannot easily be separated from the antifeatures that may be present.
Some people blame google, others blame manufacturers, others blame linux devs…I think there’s blame to go all around. But regardless of who’s fault it is, until the proprietary driver blob issues are fixed, the FOSS aspects of android are more read-only than read-write. 🙁
I’m not familiar with it, but that does sound frustrating.
Alfman,
Yes, there is too much blame to go around.
Hopefully Fuchsia will be better. (Yes, I know, it could go the other way).
Instead of blame better to demand upstream GNU/Linux ARM drivers. That is the solution to the problem you are describing. Other solutions we often talk about still involve binary ARM drivers and as such you will never have any control over it and will always be affected by planned obsolesce. Not being able to do much about it when you upgrade your OS and some hardware stops working …
Geck,
Everyone deserves blame on this for their collective stubbornness over decades. This stubbornness continues to this day and there is zero indication of anything changing. This is the past, present and future of linux on ARM. Everyone will continue blaming others without any compromise themselves. I know we’ve talked about it before and you were 100% adamant that linux shouldn’t change on philosophical grounds, but the truth is that solves nothing. I’m not into preaching fixed philosophical constraints when the result causes real world problems. There needs to be a balance.
Ultimately I’ve lost any hope for linux to solve this because the will just isn’t there. Being pragmatic, I think the world needs a new platform to solve the problem and threaten linux enough with competition that they start feeling the need to do better instead of being so damned complacent.
@Alfman
If Intel and AMD can then so can Broadcom. On how to resolve this. Give them some initiative. That is lets say 30% of hardware in a public tender must include FOSS drivers. And lets see after who will remain stubborn and who will not do that anymore.
Geck,
Who’s going to enforce that? I understand your position, but from my POV it’s the same old empty promises and I have very little hope for the industry to get past it’s own stubbornness. We’re well past the point of expecting things will work themselves out. I would have loved for linux to address it, but they haven’t and they won’t. So with that in mind I for one am ready for a new competitor to take the place of linux if that’s what it takes to grease the wheels of progress for FOSS.
As a staunch supporter of FOSS, I don’t think it helps to deny that stubbornness and inaction keeps holding us back. I am reminded of this every time I buy a new phone and it’s the exact same BS as before. We all agree that binary blobs suck, but it’s objectively worse when the entire linux kernel is the binary blob. FOSS supporters deserve more progress than this and I’m not willing to wait on linux till I’m dead. If a viable FOSS competitor shows up and are willing & able to addressing such problems, then I’m going to vote with my feet and I think others might too.
In all sincerity, I never intended to put down linux, but its leaders need to get the damn message that we’re all sick of waiting for it to get fixed. I have no more patience to give over excuses for systematic complacency. I realize this puts us at odds with one another and I can respect your own choices, but I don’t think you realize how much pent up demand there is for linux devs to get over themselves. We want to solve the binary kernel problem once and for all and if it means stable ABIs are necessary to decouple drivers then so be it.
But again it’s the blobs you are complaining about. Not FOSS. Hence if something else will come in the future. If it won’t be FOSS you will likely be in worse situation compared to now. As for who can enforce FOSS in public sector. I guess the answer to that is politicians. As this is not technical debate anymore. But when looking on how politicians deal with lets say environment. I know it ain’t going to happen anytime soon. Due to current geopolitical situation what might happen is a region such as Russia or China could embrace GNU/Linux in their public sector. In western countries a lobbyist from Microsoft will likely always outperform a lobbyist on a Debian forum. That much is true.
Geck,
I’m not complaining about FOSS, but Linux is not getting us the benefits of FOSS on mobile today. After all those binary kernel blobs are linux! This has been an unsolved problem for too long and I’m done waiting. If another FOSS platform viably solves the problem I will welcome the desperately needed new competition.
If it won’t be FOSS then it won’t fit my criteria, but that doesn’t make me wrong to call for more FOSS competitors.
That’s great as a wishlist item, but it’s been stalled for decades and I am personally not willing to wait longer for something that is very unlikely to happen.. If a linux competitor can get us closer to FOSS OS development on mobile than android/linux can, then I say bring it.
Yeah western politicians are not going to fix this.
@Alfman
I don’t have a problem with that at all. That is if some other FOSS “kernel” emerges that will change things in a way FOSS drivers will be made for mobile hardware instead of the blobs. As in that case GNU/Linux will likely benefit from it too. I see no special reason on why the drivers wouldn’t get ported and upstream after. AFAIK Fucshia won’t be that, though. That is what you get instead is a mini kernel and blobs. Not mini kernel and FOSS mobile hardware drivers. But lets wait and see. It’s not like we have much control over it anyway.
Geck,
If manufactures provide FOSS drivers then that’s great. But everyone knows that this has been a decades long stalemate already and that’s the problem. For all this waiting linux has not made nearly enough progress! This is not good enough!
You’ve been 100% adamant that linux not take any responsibility for its role in the stalemate. You want to stay the course even though it means users will never able to independently build a working kernel. While I commend linux for promoting FOSS on PC, they deserve credit for that, but their inaction today is harming FOSS on mobile. There are too many excuses that shift blame but don’t solve the problem and never will! I for one am done with these excuses and am ready for a new competitor who’s finally willing and able to make progress.
I don’t know what Fucshia phones will be like or if they fit the bill. There’s still a risk of google botching it all up, like a high dependence on proprietary services. But if we can build and run our own kernels across the board that’s a HUGE step over what android/linux offers today even if drivers are closed.
No longer would we be dependent on manufactures to update our phones. We could reuse the drivers we have and build new kernels for phones even when the manufacturers have abandoned them. Being able to independently build updates for unsupported phones would be a big step in combating e-waste. So yeah if the linux game plan is to wait indefinitely for manufacturers to fix it when we’ve already been at a stalemate for decades, then I say it’s time for new FOSS competition to step in and focus on pragmatic solutions where linux has failed.
@Alfman
You seem to be rather convinced that you don’t really need FOSS drivers to achieve what you are after on mobile hardware. And seem to feel there is something inherently different on mobile hardware. Compared to the desktop. Hence as i said best to wait and see. That is if you really will be able to do what you said you would like to do in comparison to GNU/Linux. That is with something like Fuchsia and a blob. And didn’t Google deploy Fuchsia and a blob on some real hardware already? Nest Hub if i remember correctly. Now do you know if you can do anything from your list. The list on what you desire the future would be like. When owning such device.
Geck,
Everyone can agree FOSS drivers would be nice to have, but android/linux haven’t delivered on this promise for decades so that point is mute. The kicker is linux (and even you personally) have no plan to fix anything whatsoever. You know manufactures don’t have an incentive to open drivers, and you’ve explicitly admitted politicians won’t solve it. You keep doubling down on a stalemate that has no end in sight. Meanwhile our inability to upgrade operating systems independently keeps us spiraling around e-waste hell.
Our human nature is to blame everyone but ourselves, but that gets us nowhere. The world desperately needs leaders to take more responsibility, and frankly that includes FOSS projects.
A FOSS kernel with a stable ABI would finally provide a path to independently supporting the operating systems on our mobiles. Of course you and I can still advocate for going further but at least we will have made substantial progress over the linux stalemate that has plagued FOSS on mobile for so long.
Obviously we’ll have to see where things go with Fuchsia, I’d give it maybe a 50/50 chance at being any good. But for the record the complaints about linux stand regardless. The lack of real competition and the defacto market share linux benefits from via association with android has lead linux leadership to sink towards complacency instead of building and rewarding a problem solving ethos. Alas I’d say this is a common problem for entities that become dominant enough to take their success for granted.
@Alfman
Politicians might still end up contributing. I just wouldn’t count on USA ones for now. At least until lets say China produces an operating system that will become relevant in the USA. Then it will likely be mandated for it to be fully FOSS (drivers included). By independently you mean you? You believe that you will be able to for example compile Fuchsia components and install them to your mobile phone? In times when you can’t even root your device officially. Or are you referring to a vendor such as Samsung for being able to do that? Or for Google to bypass Samsung on Samsung phones and Google updating Samsung phones? And as for the bugs in the binary drivers? Not all that realistic is it? Anyway. Good luck with that. Personally i will stick with FOSS drivers as being the way forward. Not from any ideological point of view. It’s just common sense in the end. As for the stalemate you are talking about. Lets first see if Fuchsia devices can in practice top the longevity of GNU/Linux based devices. As if you get 5 years today for some GNU/Linux based flagship device. And lets say you would get 4 years when Fuchsia based. That would be a rather big fail wouldn’t it? Due to lets say Google having tighter schedule then GNU/Linux. In regards to long term releases.
Geck,
So we are in agreement, relying on them is a non-solution. That’s the thing, once we rule out all non-solutions, we’re forced to look at pragmatic ones. Continuing down the path of a decades long stalemate is a non-solution.
So…you are criticizing Fuchsia because it might fall short of ideals that android/linux are already falling short of today. Ok then. Hopefully Fuchsia does tackle our major pet peeves with android/linux – maybe they will maybe they won’t. Either way though logic dictates that progress gets measured from where linux actually is at and not from where you wish linux were at.
It’s called wishful thinking. I get it, you wish we had FOSS drivers, and so do I…but that doesn’t get shit done and it never will. After decades of stalemate I am no longer interested in advocating for non-solutions. You can go ahead and preach them, but we’re all going to be dead before we see any results. Wishful thinking has created a void in linux leadership’s ability to achieve practical solutions for users, which is why FOSS desperately needs new competition to push FOSS forward.
This is where stable ABIs can help, we need to build kernels independently without being dependent on manufacturers for every OS build. It could finally give us practical avenues for FOSS kernel development on mobile.
@Alfman
It won’t work. Your proposal. You will buy a mobile phone and if by any chance you will have root access and will be able to upgrade lets say Zircon on it. OK fine. But what will happen is Fuchsia A on your mobile phone will support OpenGL A. And the blob provided with your mobile phone will advertise OpenGL A support. Then one year later Fuchsia B will get released and it will require OpenGL B. Your proposal is just not feasible. If your proposal would be a proper solution then rest assured GNU/Linux would already implement it.
In my opinion it should be illegal to prevent sideloading on Android and iOS. Side loaded apps should have unrestricted access to platform APIs. On why this wasn’t done yet is beyond me.
Geck,
I actually think sandbox restrictions can be useful, but the owner needs to have the ultimate say, not google.
Also, I really don’t follow google’s justification for permissions to be based on the install API used. Why are they making this work differently than how all other application permissions work? Even if an app gets installed via google’s app store, it doesn’t seem like that should determine an app’s security policy IMHO. Why shouldn’t it be created as just another ordinary permission?
If you mobile phone is able to ask you if you grant some application some permission. And you then chose “Yes” or “No”. There is no issue there. On why they did what the news say. Likely they made an analysis in regards to a certain widespread attack vector. And came to a conclusion this API is abused the most when an application is installed from outside of some store. Likely from some “pop-up” on some web page. If i read it correctly people will still be able to enable this functionality in such applications. Hence this is not as bad as tying some API to Google Play.
Geck,
There is a real tradeoff between security and open access.
We had the almost same exact discussions during Windows XP times. All apps decided to run as Administrator will full access to users’ hard drives. First there were annoying UAC popups, and gradually Windows became more locked down.
There is still an “escape hatch”. Enabling developer mode, and using ADB will give you more access. But of course, that could be the next battleground.
In general i am OK if something is behind a checkbox. Beyond that laws should prevent things like not being able to enable root account. If enabled applications should still work the same after. Mandating of supporting sideloading on iOS. Usage of platforms APIs to not be restricted for such applications … Hence in the end it’s up to you to make a tradeoff or not.
Geck,
Thanks to DRM requests from Netflix, Disney etc, it has become a binary choice.
Many devices still offer an option to unlock root and / or boot loader. However as soon as you do that, many apps will either will refuse to run, or run degraded (480p?). In my experience with Samsung, that also included fitness apps, even though I did not even go full root.
Given computers, especially mobile devices have become content consumption machines, I do not know an easy solution to this.
Yes. That should be illegal.
Geck,
I would say “good luck with that”.
And I see them saying “we agree that you have the right to unlock your device. we the content providers also have the right to refuse service on that platform”
Given our current state of copyright laws (in any western country), how do you think this will go?
@sukru
First things first. Making it mandatory to allow root access on Android and iOS is a good start. Lets do that first.
The EU is supposedly working towards mandating sideloading. But keep in mind this is the EU, which tends to start with lofty goals and then progressively water them down as interest groups get involved, so let’s wait and see.
For example, should the PS5 have open sideloading, considering the very business model of game consoles is to give the hardware at cost and then make a profit from license fees charged to developers? iOS is inexcusable because they make a decent margin on the hardware alone, but how do you legislate “decent margin”?
kurkosdr,
Xbox allows “side loading”. Since Xbox One, you can pay a one time fee to unlock consoles in “dev mode”. But that is mutually exclusive with commercial games. i.e.: it becomes a “dual boot Games or Dev” situation.
Which is a reasonable compromise. It allows playing God of War Ghost of Sparta for example, in high res (which is not currently possible on the PS5, unfortunately, except for streaming):
https://www.youtube.com/watch?v=sO8B2GXsJsU
@kurkosdr
I would say that there is likely a couple of million gamers and a couple of billion mobile phone users. One area affects somebody hobby and there still is a lot of competition available if you are a developer. Another area affect human lives in general. Point being i don’t care if Android and iOS are treated differently. Compared to lets say some gaming platform.
So now not only can we not install an app for call recording from the Play Store, but we will be SOL installing one ourselves also.
So how the heck are we supposed to get call recording. Do NOT say buy a Pixel!
Thom – you say “a chilling effect on the wild innovation we see in the Android world”
What can sort of concretely useful things or apps does the ‘wild innovation’ on the Android platform currently offer to the end user that iOS does not offer?
That’s a genuine question. I know that on forums like this website populated largely by people inherently interested in tinkering with technology the debate on issues like platform privacy, security, OS restrictions and walled gardens tends to be conducted at the high principle level and is usually dominated by the tech variant of Neo-liberal free market ideology but I don’t often get a sense of what – concretely – an imposed platform free market would offer the average end user.
If side loading were imposed on iOS for example what sort of concrete real world applications and functions would be possible that are not possible now, and how would they benefit the average user?
Emulators are a good example. Apple doesn’t want them because they threaten their App Store, so they are banned from the App Store. Google tried to ban an emulator from the Play Store (psx4droid) for the same reason, until everyone was sideloading it, so after that they let every other emulator in. This is the good thing with sideloading: It keeps OS vendors honest.
Fortnite allowing out-of-store in-game purchases in the sideloaded version is another example.
Strossen,
Obviously they block and tax alternatives, which deprives the market of competition. But we also should consider that walled gardens are an enabler of more serious types of abuse.
https://www.techtransparencyproject.org/articles/apple-censoring-its-app-store-china
When corporations engineer restrictions into consumer owned devices, those very same mechanisms can and do become instruments of government oppression. Open platforms are much better for protecting rights.
Meanwhile in the real world, unless you dump your phone into landfill every 18 months or so, raise your hand if you’re on Android 12. Looking at the current stats it’s 11%. Yes, it’s the proliferation of platforms running Android and their short-livedness with Google leading and owning their own hardware platform, but I sort of look at these Android dev updates as if they were express trains passing by.