A few days ago we brought you word that Google was looking to crack down on “sideloaded” Android applications. That is, software packages installed from outside of the mobile operating system’s official repository. Unsurprisingly, a number of readers were outraged at the proposed changes. Android’s open nature, at least in comparison to other mobile operating systems, is what attracted many users to it in the first place. Seeing the platform slowly move towards its own walled garden approach is concerning, especially as it leaves the fate of popular services such as the F-Droid free and open source software (FOSS) repository in question.

But for those who’ve been keeping and eye out for such things, this latest move by Google to throw their weight around isn’t exactly unexpected. They had the goodwill of the community when they decided to develop an open source browser engine to keep the likes of Microsoft from taking over the Internet and dictating the rules, but now Google has arguably become exactly what they once set out to destroy.

Today they essentially control the Internet, at least as the average person sees it, they control 72% of the mobile phone OS market, and now they want to firm up their already outsized control which apps get installed on your phone. The only question is whether or not we let them get away with it.

Must be This High to Ride

First, “sideloading”. The way you’re supposed to install apps on your Android device is through the Google Play store, and maybe your phone manufacturer’s equivalent. All other sources are, by default, untrusted. What used to be refreshing about the Android ecosystem, at least in comparison, was how easy it was to sideload an application that didn’t come directly from, and profit, Big G. That is what’s changing.

Of course, the apologists will be quick to point out that Google isn’t taking away the ability to sideload applications on Android. At least, not on paper. What they’re actually doing is making it so sideloaded applications need to be from a verified developer. According to their blog post on the subject, they have no interest in the actual content of the apps in question, they just want to confirm a malicious actor didn’t develop it.

The blog post attempts to make a somewhat ill-conceived comparison between verifying developer identities with having your ID checked at the airport. They go on to say that they’re only interested in verifying each “passenger” is who they say they are for security purposes, and won’t be checking their “bags” to make sure there’s nothing troubling within. But in making this analogy Google surely realizes — though perhaps they hope the audience doesn’t pick up on — the fact that the people checking ID at the airport happen to wear the same uniforms as the ones who x-ray your bags and run you through the metal detector. The implication being that they believe checking the contents of each sideloaded package is within their authority, they have simply decided not to exercise that right. For now.

Conceptually, this initiative is not unlike another program Google announced this summer: OSS Rebuild. Citing the growing risk of supply chain attacks, where malicious code sneaks into a system thanks to the relatively lax security of online library repositories, the search giant offers a solution. They propose setting up a system by which they not only verify the authors of these open source libraries, but scan them to make sure the versions being installed match the published source code. In this way, you can tell that not only are you installing the authentic library, but that no rogue code has been added to your specific copy.

Google the Gatekeeper

Much like verifying the developer of sideloaded applications, OSS Rebuild might seem like something that would benefit users at first glance. Indeed, there’s a case to be made that both programs will likely identify some low-hanging digital fruit before it has the chance to cause problems. An event that you can be sure Google will publicize for all it’s worth.

But in both cases, the real concern is that of authority. If Google gets to decide who a verified developer is for Android, then they ultimately have the power to block whatever packages they don’t like. To go back to their own airport security comparison, it would be like if the people doing the ID checks weren’t an independent security force, but instead representatives of a rival airline. Sure they would do their duty most of the time, but could they be trusted to do the right thing when it might be in their financial interests not to? Will Google be able to avoid the temptation to say that the developers of alternative software repositories are persona non grata?

Even more concerning, who do you appeal to if Google has decided they don’t want you in their ecosystem? We’ve seen how they treat YouTube users that have earned their ire for some reason or another. Can developers expect the same treatment should they make some operational faux pas?

Let us further imagine that verification through OSS Rebuild becomes a necessary “Seal of Approval” to be taken seriously in the open source world — at least in the eyes of the bean counters and decision makers. Given Google’s clout, it’s not hard to picture such an eventuality. All Google would have to do to keep a particular service or library down is elect not to include them in the verification process.

Life Finds a Way

If we’ve learned anything about Google over the years, it’s that they can be exceptionally mercurial. They’re quick to drop a project and change course if it seems like it isn’t taking them where they want to go. Even projects that at one time seemed like they were going to be a pivotal part of the company’s future — such as Google+ — can be kicked to the curb unceremoniously if the math doesn’t look right to them. Indeed, the graveyard of failed Google initiatives has far more headstones than the company’s current roster of offerings.

Which is so say, that there’s every possibility that user reaction to this news might be enough to get Google to take a different tack. Verified sideloading isn’t slated to go live until 2027 for most of the world, although some territories will get it earlier, and a lot can happen between now and then.

Even if Google goes through with it, they’ve already offered something of an olive branch. The blog post mentions that they intend to develop a carve out in the system that will allow students and hobbyists to install their own self-developed applications. Depending on what that looks like, this whole debate could be moot, at least for folks like us.

In either event, the path would seem clear. If we want to make sure there’s choice when it comes to Android software, the community needs to make noise about the issue and keep the pressure on. Google’s big, but we’re bigger.