Author here. I admit I am rather startled by the tone of many comments here and the accusations of disingenuity. Splitting hairs about the origin of the term "sideload" does not change the fact that those who promote the term tend to do so in order to make it feel deviant and hacker-ish. You don't "sideload" software on your Linux, Windows, or macOS computer: you install it.
You have the right to install whatever you want on your computer, regardless of whether that computer is on your desk or in your pocket. That's a hill I'll die on. I'm dismayed to see that this sentiment is not more widespread in this of all communities.
Hey, question. While I'm also miffed about Google's decision and see your point about the term sideloading, there is another elephant in the room you seem to not be addressing here.
You write:
> “Sideloading is Not Going Away” is clear, concise, and false_
But isn't Google saying that you will still be able to sideload via ADB? Which would mean their statement is true, and that your claim that Google's statement is files is itself false?
I'm so confused why you never even mention ADB or its relevance to sideloading, which they refer to rather explicitly in their blog post. At the very least, if you think ADB doesn't change anything, you could mention it and say so. Could you explain this seemingly critical omission?
Forcing ADB may as well be a ban, if you don't see that, you're pretty out of touch with consumers. Sideloading is already hard enough for many, forcing the use of an extra computer, a dev tool in the CLI, and dev mode is way way outside what people will do
The reason for its omission should be obvious. First, most people who "sideload" apps do not have ADB installed, and may not have the technical knowledge to do so. Second, the ability to do so can be taken away just as arbitrarily as the right to do so without it.
Not only will sideloading via ADB continue to work, installing from most other third-party app stores will continue to work. The developers on the Amazon, Samsung, and Epic app stores won't have a hard time with the developer verification process. F-Droid is in a uniquely inconvenient position that they have a legitimate app store, but its design causes them to have a hard time with developer verification.
> won't have a hard time with the developer verification process
Unless any government powerful enough has reason to make Google reject developers. Hell, doesn't even have to be a government. Do anything that annoys Google, goodbye rights for your app to be installed on any Android. Why would you ignore the obvious and main caveat? It doesn't matter what store it "continues to work on". Google can revoke privileges overnight with little to no recourse for the developer, regardless of the merit of such action, the usefulness of the app, or how much people want/need that app. This is literally heading in the direction of Kafkaesque.
I would say the situation is worse as this "subscription-esque" model is "spreading" to areas beyond software. Exercise equipment like ellipticals and bicycles - whose software is/could be borderline +/- resistance level trivial - has been moving to "only works with an online subscription" business models for a long time.
I mean, I have had instances that controlled resistance with like a manual knob, but these new devices won't let you set levels without some $30+/month subscription. It's like the planned obsolescence of the light bulb cartels of the 1920s on steroids.
Personally, I have a hard time believing markets support this kind of stuff past the first exposé. I guess when you don't have many choices or the choices that you do have all bandwagon onto oligopoly/cartel-like activity things, pretty depressing, but stable patterns can emerge.
Heck, maybe someone who knows the history of retail could inform us that it came to software "from business segment XYZ". For example, in high finance for a long-time negotiated charging prices that are a fraction of assets under management is not uncommon. Essentially a "percent tax", or in other words the metaphorical "charging Bill Gates a million dollars for a cheeseburger".
EDIT: @terminalshort elsethread is correct in his analysis that if you remove the ability to have a platform tax, the control issues will revert.
That planned obsolescence thing on light bulbs isn't the entire story. Light bulbs will last longer if driven less hard, due to the lower temperature. But that lower temperature also means much lower efficiency because the blackbody spectrum shifts even further into the infrared. So some compromise had to be picked between having a reasonable amount of light and a reasonable life span.
But yeah agree, this subscription thing is spreading like a cancer.
I'm not an expert on the case law, but supposedly United States v. General Electric Co. et al., 82 F.Supp. 753 (D.N.J. 1949) indicates that whatever design trade-offs might have existed, corporate policy makers were really just trying to screw consumers [1] (which is why they probably had to agree on short lifespans as a cartel rather than just market "this line of bulbs for these preferences" vs. "this other line for other people" -- either as a group or separate vendors). I keep waiting for the other shoe to drop where they figure out how to make LED bulbs crappy enough to need replacement.
Leds are already awful. I already lost 4 of 10 led light bulbs I boughtast year. I hope they will be replaced. It's because every led bulb has a small transformer inside and it fails quite quickly
I think its a heat dissipation issue. I have some overhead LED lights that replaced some halogen bulbs and they have huge metal heat sinks on the back and have all lasted 10+ years. Unfortunately they are no longer sold but I did buy a few spare just in case.
I got one of these free energy audit things which included swapping out up to 30 or so bulbs with LEDs. Whatever contractor did it seems to have gotten the cheapest bulbs they could, and the majority of them have failed by 4 or 5 years later. So far so good on the name brand ones I replaced them with.
Yes, but the compromise didn't have to be an industrywide conspiracy with penalties for manufacturing light bulbs that were too long-lasting and inefficient. But it was. Consumers could have freely chosen short-lived high-efficiency bulbs or long-lived low-efficiency ones.
In fact, they could have chosen the latter just by wiring two lightbulb sockets in series, or in later years putting one on a dimmer.
The reason subscriptions are spreading everywhere is that stock markets and private investors usually value recurring revenue at a much higher multiple than non-recurring revenue. The effect can be so large that it can be better to have less recurring revenue than more non-recurring revenue, at least if you are seeking investment or credit.
It creates a powerful incentive to seek recurring revenue wherever possible. Since it affects things like stock prices and executives and sometimes even rank and file employees often have stock, it's an incentive throughout the organization. If something is incentivized you're going to get more of it.
In the past it was structurally hard to do this, but now that everything is online it becomes possible to put a chip in anything and make it a subscription. We are only going to see more and more of this unless either consumers balk en masse or something is done to structurally change the incentives.
All very true and "balk en masse" is what I meant by "first exposé". (Ancient wisdom, even, if you think about individuals and mortages/car loans and having a steady job, etc. rather than just businesses.) Maybe we'll anyway see some market segments succeed with "pay 2x more for your screwdriver, but it will at least be your screwdriver" slogans, and then have screwdrivers to do with what we will, like the proverbial "pound sand". ;-)
I agree with your point about "install" vs "sideload".
> Google’s message that “Sideloading is Not Going Away” is clear, concise, and false
Given your(and my) definition, this statement is false. Google isn't taking away sideloading, you can still use adb. I'd say using adb to load an apk from another device is the proper use of "sideloading".
What Google is doing is much worse, they are taking away your ability to _install_ software.
And yes, HN loves splitting hairs. But if it wasn't for the hairsplitting, there probably would be be much discussion. Just most people agreeing with you and a few folks who would prefer to give up freedom for security.
Hey, I hope you have a nice day. F-droid is one of the communities which was really a key role in, what open source project should I recommend if given the power to, for people to gain maximum impact on, and f-droid was one of the tops in that charts, so much so that I really tinkered with android apps creation with rust/tauri just to create an android app for f-droid (building android apps is hard I must admit, which makes my appreciation for apps on f-droid even more lovely)
> You have the right to install whatever you want on your computer, regardless of whether that computer is on your desk or in your pocket. That's a hill I'll die on
I feel like there are some phones, I will say my honest experience, I had a xiaomi phone which required me to unlock the bootloader for me to root it/ remove the spyware that I feel it has, I never felt safe really (maybe paranoia?) but I wanted an open source operating system on it and that required me to unlock my bootloader
Which required me to create an MI Unlock / MI account which then later required me to open up a windows computer and try to do things with the windows computer
I didn't have a windows computer, I am a linux guy and I didn't want to touch windows and I tried any option available on linux (there was a java thing and some other exploit too but both failed)
Later, I tried to actually install win-boat and tried to install the mi tool in it after so many nights of work and I tried and it actually opened but it asked me for the otp to sign up but I don't know if I overwhelmed their system or not but their OTP just straight up didn't show on the phone's sim I had registered on.
That OTP not coming after 5-6 tries, I am not sure if they had detected it was win-boat or what, but idk, that effectively locks me out of ways to unlock the device and remove some spyware functionality I think it has.
I feel like this case made me feel as if although I had a device, it feels like a license when you think about it. This is true for many other consumer devices as well and thus, people accepting the fact that their devices have become similar to licenses, not hardware which they own, but rather software which they rent
> I'm dismayed to see that this sentiment is not more widespread in this of all communities.
I feel like your message is in the right heart, and its honestly okay, sad even, that some part of the community didn't respond to your message in agreement.
But Honestly, please don't lose hope because of this, You and people/foundations like f-droid,linux etc. inspire a sense of confidence for a good future while actively working on it. I was thinking of trying to host some f-droid mirror but I didn't personally because I was a little skeptical of getting any notices or anything after the f-droid team had created a blog post about something similar.
Also one thing, I would try to tell you is that you are trying your best. And that's all that matters. What doesn't matter is the past or the future or how the community responds but rather doing what you think is right with correct intentions which I think you do a perfect job in.
Doing the right thing can be difficult but maybe in a world where doing the right thing isn't rewarded as much in even mere appreciation or sharing the sentiment whereas doing the wrong thing is financially rewarded. its a complicated world we live in, but hopefully, we all can try to make it a little more beautiful for us and our future generations by trying to do things the right way no matter how hard they are, just because its the right thing.
I may speak these things but I myself regularly contradict these. So I don't feel the best guy speaking this stuff but I just want to say that f-droid really means a lot to me, a recent example is how I ditched that xiaomi phone, used my mum's old moto phone, tried to install termux from playstore but it couldn't download for some reason from play store because it was android 8 yet theoretically it should work, but I then opened up f-droid and installed it from there and I am running a termux/gitea server on it now :)
Please, have a nice day, F-droid/you deserve it, I just hope that you recognize that there are people's lives that you have touched (like my termux thing and there are countless other stories as well) and how impactful the project is.
Lets use this comment as a way to show our appreciation to f-droid in whatever ways it has touched our lives and how effectively google's recent moves are really gonna impact f-droid/ hurt us as well. How I wouldn't have been able to run git server on my phone if it wasn't for f-droid and so much more.
put a fork in it, it's done,almost!
android that is.
linux phones are comming up fast, and will be set up to run the droid apps we like.
but big props to fdroid
just used "etchdroid" to transfer a linux iso to a thumb drive and boot a new desk top, and if I get a few bucks ahead I will buy a dev board from these guys
https://liberux.net/
flinuxoid?, flinux?
Google really knew what they were doing by hiring Marc Levoy. The Google camera is the only thing keeping me from getting something other than a pixel phone.
I agree it's a pointless distraction, but it's a distraction you instigated by trying to language police your own supporters. I and most others who use the term sideloading don't use it because we want to make sideloading "feel deviant and hacker-ish", we use it because it's the commonly accepted term for installing apps outside the app store. I'm open to alternative phrasing, but "direct install" doesn't work because installing apps from F-Droid isn't a "direct install" and "installing" doesn't work because that doesn't distinguish from installing from the Play Store. "Sideloading" is simply the correct word, and I've yet to see a better alternative. There's no reason to be ashamed of it, or accuse people of being part of some conspiracy for calling it that.
If anything, the fact that Google feels the need to disingenuously argue "sideloading isn't going away" suggests to me that the term sideloading has a good reputation in the public consciousness, not a negative one.
Let's just focus on the fact that Google is trying to take away Android users' ability to install software that Google doesn't approve of, and not stress so much about what words people use to describe that.
> and "installing" doesn't work because that doesn't distinguish from installing from the Play Store
I'm not choosing sides, but why do you need a term to distinguish from installing from the Play Store? On my Debian machine I install git from apt (officially supported) but also install Anki from a tarball I downloaded from a website. Same term `install`.
This comment is funny because you have defined these words to be as such
You have defined installing to be specifically from play store and sideloading as everything except it.
Google isn't trying to prevent installing, just sideloading works in this sentence because of what you have already defined but you are using this sentence in defense of that....
As OP stated, installing can mean on debian as an example, installing from both apt or either tarballs. Both are valid installations
So it is the same for google/android as well yet google is trying to actively prevent one part of the installing or make it really extremely hard to do so.
It is a dangerous precedent. And I would say that it severely limits what you mean by installing.
I got an PC, and I got internet connection, usually it isn't trying to prevent what I install if I am on linux.
Yet I am on android and earlier it used to do the same but now its a slippery slope where it either requires me to use adb or keep another device at me at all times if I ever want to install software on it.
Not because its not that these phones can't do it, In fact that they already do but they are removing it, simply because they can.
No, that is not the definition I was using. "Sideloading" is a subset of installing, not disjoint from it. If Google were to prevent installing, it would prevent sideloading, but it would also prevent installing from the Play Store, which clearly they don't want.
It's a very dangerous precedent, but one that's difficult to discuss without having a name for the kind of installing that Google is trying to prevent.
I don't know, why do we need a term to distinguish brown from dark orange? The term emerged organically because the built-in app store is the most common way to install apps on mobile phones (and the only way on iOS), but on Android you can also install apps from other sources without needing Google's permission so people came up with a catchy name for that.
It's convenient because now we can say "Google is killing sideloading" as a very succinct way to describe what's happening when we're arguing against it. "Blocking users from installing apps not approved by Google" works equally well but is a bit more wordy. I personally prefer the latter because I think it's a little more precise, but trying to imply people have to phrase things that way or they're part of some conspiracy does nothing but alienate your supporters and distract from the real issue.
> Splitting hairs about the origin of the term "sideload" does not change the fact that those who promote the term tend to do so in order to make it feel deviant and hacker-ish.
That is not a fact, that is your opinion. Lots of people say "sideload" without trying to convey such negative meanings. For better or for worse, the term has entered the common lexicon and I very rarely see it used with negative connotations attached to it.
> Lots of people say "sideload" without trying to convey such negative meanings
Sure, but they effectively do even if they're not trying to. It comes off like you're up to no good or doing something dangerous. Like GP said: deviant.
>Sure, but they effectively do even if they're not trying to.
What specific acts are referring to? Is it just their recent plans to restrict sideloading? This feels circular. "Google is evil because they're trying to restrict sideloading. They're also extra evil because trying to demonize sideloading. How? By restricting sideloading!"
>It comes off like you're up to no good or doing something dangerous. Like GP said: deviant.
Yes, but only insofar as if you're not taking the primary route, you're taking the "side" route. Or you're "deviating" from the intended route. None of that actually implies you're a "deviant" for doing so, any more than a driver taking side streets to shave 30s is a "deviant".
I think the recent push to restrict "sideloading" made people realize that the term itself helps Google frame it to normies as a fringe, non-standard thing that needs controls around it. When in reality you're just installing software on a device.
>I think the recent push to restrict "sideloading" made people realize that the term itself helps Google frame it to normies as a fringe, non-standard thing that needs controls around it.
No, it made all the pro-sideloading people (for lack of a better term) find any reason to hate google even more, including flimsy arguments about how "sidleoad" is some sort of sinister psyop. I still haven't seen any evidence to suggest "sideload" has any negative connotations to the average "normie", beyond its meaning of "install from third party source"[1]. All I've seen are endless speculation that it's a google psyop in techie/hacker[2] circles, like this post.
>Splitting hairs about the origin of the term "sideload" does not change the fact that those who promote the term tend to do so in order to make it feel deviant and hacker-ish.
Can you corroborate this? At least for me, the whole idea that "sideloading" has negative connotations only came up as a result of this debacle, and the only evidence I've seen are some very careful readings of blog posts from Google. The word itself hardly has any negative connotations aside from something like "not primary", which might be argued as negative, but is nonetheless correct.
>You don't "sideload" software on your Linux, Windows, or macOS computer: you install it.
Right, because those devices don't have first party stores. Windows and Mac technically do, as does some Linux distros, but they're sufficiently unpopular that people don't think of them as the primary source to get apps. Contrast this to a typical Android or iOS phone.
I don't think this is so much a question of sources & corroboration as it is of language.
Regardless of the origins of the term "sideload", the language implies a non-standard practice. The prefix "side-" may be used in some software contexts to describe normal, non-deviant software, but only in cases where the software in question is considered auxiliary. In general, anything described as "side-*" is connoted to be surplus / additional / non-primary at best - adding that to the term "load" & the loading action itself is surplus/additional/non-primary. It's automatically considered non-standard.
> those devices don't have first party stores
This only supports the argument. If somebody felt an alternative term was required on Android because the first-party store was the primary source of software, the only reason they could have for needing such an alternative term would be to explicitly differentiate that alternative source as unofficial/non-standard.
>Regardless of the origins of the term "sideload", the language implies a non-standard practice.
Because it is non-standard. Like it or not, the intended experience is that you get apps from the play/app store, and for most people that's exactly what they do. This is a descriptive statement, not a normative one. Accepting it doesn't imply you oppose the freedom to run whatever code you want. The language of "sideload" or whatever is directly downstream of this. Just because google is using language that reflects the current state of affairs, doesn't mean they're engaging in some sort of sinister psyop with their word choice, as the OP is trying to imply.
> This is a descriptive statement, not a normative one.
It's both. It's not like "sideloading" is a part of natural language that just happened to evolve this way to describe the practice. The terminology was consciously chosen by the same people who designed the OS to describe it. The people who argue against using this term aren't doing it in some accusatory way, like "you use this term, therefore you're an evil brainwashed minion of the enemy", but rather by using language to not set up their argument on the enemy's terms, no matter how insignificant.
It's like how "jaywalking/jay walking" was popularized - the term itself was pretty crass for the time, the word "jay" conjuring thoughts of some kind of drooling, unintelligent yokel. Back when car infrastructure was still in its infancy, how would you argue that cars shouldn't dominate all streets and cities when the government- and industry-approved name for your action was literally "stupid walking"?
>It's like how "jaywalking/jay walking" was popularized - the term itself was pretty crass for the time, the word "jay" conjuring thoughts of some kind of drooling, unintelligent yokel. Back when car infrastructure was still in its infancy, how would you argue that cars shouldn't dominate all streets and cities when the government- and industry-approved name for your action was literally "stupid walking"?
That makes sense because as you said, "the word "jay" conjuring thoughts of some kind of drooling, unintelligent yokel". The same can't be said for "side", aside from vague accusations that it's not "official" therefore normies think it's bad, but I can't see how you can get away from that accusation without using meaningless phrases like "type 2 install" or whatever (though I'm certain that would get similar amounts of ire for being "second class citizens" or whatever).
Debian has had a "first party store" since the early 90s, and the truth is the diametrical opposite of "they're sufficiently unpopular that people don't think of them as the primary source to get apps". It's been almost the only way I install software (that I didn't write) on my Debian and Ubuntu machines since I moved to Debian. This is true of most Debian and Ubuntu users.
>Debian has had a "first party store" since the early 90s, and the truth is the diametrical opposite of "they're sufficiently unpopular that people don't think of them as the primary source to get apps".
Aren't those all considered first party apps? Sure, debian aren't the authors of nginx or whatever, but they're the people building, packaging it, and adding patches for it. It's a stretch to compare them to the play store or app store.
No, it's not a stretch at all. The user experience is the same, except that Debian and F-Droid apps don't come with antifeatures built in. The only friction is around who to report bugs to.
For one, it doesn't contain non-free software, and therefore can't be the primary source of software. Maybe you're a Stallman acolyte who only runs free software, but that's not feasible for the average user.
The average user might have one or two non-free programs they depend on that aren't websites. Maybe AutoCAD, or Photoshop, or SketchUp, or Excel, or the driver for their oscilloscope, or Dark Souls. Everything else can easily be free software or webapps. So an "app store" that doesn't contain non-free software can be the primary source of software, and for almost all Debian or Ubuntu users, it always has been.
The average Ubuntu user doesn't even have those one or two non-free programs. After all, Autodesk doesn't provide a version of AutoCAD for Linux in the first place.
> The word itself hardly has any negative connotations aside from something like "not primary", which might be argued as negative, but is nonetheless correct.
Android has an APK installer built in. Opening an APK file launches the installer and installs the application, just like opening an MSI file on Windows launches built-in Microsoft Installer and installs the application.
Google have gradually added impediments to this over this years, such as a requirement to toggle a checkbox in the settings to enable installation, and later some prompts about letting Google scan the package, but calling the system's built-in application installation mechanism "not primary" is absurd.
>but calling the system's built-in application installation mechanism "not primary" is absurd.
So you're arguing that because play store installs and random .apk installs both goes through packageinstaller, the concept of a "primary" install method doesn't exist?
Yeah, and they are the primary way to install software for nearly every distro that has them.
And even when people install software on their user's home only, we don't call it anything different.
It's correct to say that "sideloading" was created to emphasize it's a deviant activity. I believe it was created by the people doing it, when they discovered hacks that enabled them. But I wouldn't be too surprised it was created by the companies trying to prohibit software installation.
>Yeah, and they are the primary way to install software for nearly every distro that has them.
>And even when people install software on their user's home only, we don't call it anything different.
But even on Android the word used is "install". When you try to install an apk, the button says "install", not "sideload". "Sideload" is only used in the context of google's blog post, where it's there to differentiate between installs from first party sources vs others. This is an important distinction to capture, because their new restrictions only apply to the latter, so something like "installing isn't going way" wouldn't make sense. "sideload" captures this distinction, and is far more concise than something "installing from third party sources". Moreover this sort of word policing reeks of ingroup purity tests from the culture wars, eg. "autistic vs person with autism" or whatever.
It doesn't, but that doesn't mean people can't call out disingenuous statements made by the OP. Posts can be directionally correct even if they contain errors, but the errors are still worth calling out.
The contradiction exists because you wrote it. If you wanted to avoid having to write a false statement and then walk it back, you could've left it out and skipped straight to explaining why those platforms' first party stores don't count in your estimation. As I recommended.
I think we could set the bar substantially higher. Don't even bother with discussion of sideloading. Talk about bounded transactions and device control.
What is needed is: Once I have purchased a device, the transaction is over. I then have 100% control over that device and the hardware maker, the retailer, and the OS maker have a combined 0% control.
First thing on the list for me is dramatically reforming the Digital Millenium Copyright Act (DMCA), which currently makes it a federal felony to provide other people any information or tools they might use to control the devices they own, ex:
> Thanks to DMCA 1201, the creator of an app and a person who wants to use that app on a device that they own cannot transact without Apple's approval. [...] a penalty of a five year prison sentence and a $500,000 fine for a first criminal offense, even if those tools are used to allow rightsholders to share works with their audiences.
In some ways, I think this is even more important than attempting to bar companies from putting in the anti-consumer digital locks in the first place: It's easier to morally justify, easier to legally formulate, and more likely to politically pass. The average person won't be totally stuck lobbing the government to enforce anti-lock rules for them, consumers can act independently to develop lockpicks.
Plus it removes the corporations' ability to bully people using your tax-dollars and government lawyers.
That bar would require infinitely good software on the hardware. Then it will be your device. Otherwise, they will constantly need to improve it. then it will be their software on your device.
Would you consider Microsoft Windows or Linux as infinitely good software? The scenario described by the GP applies 100% to most personal desktop and laptop computers.
What does this even mean? You don't want software updates? Or strictly only software updates that are 100% aligned with your wishes whatever they may be at the time?
No forced updates, no downgrade prohibition, no bootloader locking, kernel GPL compliance (with drivers that can be loaded in it, even if they are closed source), no remote attestation.
The bare minimum so that I can use the device I bought as I wish, even if the manufacturer later decides to "alter the deal".
Most of the time, software updates remove features, change things around for no good reason (breaking our workflows), or add unwanted features.
We really should separate pure bugfix updates (which include security updates) from feature updates. We nearly always want the former, but not necessarily the latter.
So much this. I totally want security fixes, but I only want security fixes. I don't want UI changes, features removed or altered, or anything with my usability upset.
My computing devices are tools I use to do my job and run my life. I don't want those tools changing without my consent.
I'll take that deal 9 times out of 10.
Why would I want updates tied to a phone if I'm going to be installing my own software with its own updates? This is already done on most software, browsers, etc.
CVE on text messages? Cool, wasn't using the manufacturer's app anyway.
Unironically, I want finished software. I don't like it one bit how the vast majority of software products today are in an "eternal beta", so to speak.
Android, in particular, is a finished product. It doesn't need yearly updates. It may need an occasional update to patch a vulnerability, but this whole "we changed the notification shade UI for tenth time because we're so out of ideas" thing has to stop.
Maybe software updates could contain things users actually want, that provide a competitive incentive for users to choose to buy the phones from specific makers?
Maybe I do, maybe I don't. It's for me to decide what updates I want, if any. Apple and Microsoft do not give you a choice. Precisely zero people wanted Copilot on their computers, but it's there anyway whether you want it or not.
I think this misses the forest for the trees here. The platforms behavior here is a symptom and not the core problem. I think the following are pretty clearly correct:
1. It's your damn phone and you should be able to install whatever the hell you want on it
2. Having an approved channel for verified app loading is a valuable security tool and greatly reduces the number of malicious apps installed on users devices
Given that both of these things are obviously true, it seems like a pretty obvious solution is to just have a pop up that has a install at your own risk warning whenever you install something outside of the official app store. 99.9% of users would never see the warning either because almost all developers would register their apps through the official store.
But there is a reason why Apple/Google won't do that, and it's because they take a vig on all transactions done through those apps (a step so bold for an OS that even MSFT never even dared try in its worst Windows monopoly days). In a normal market there would be no incentive to side load because legitimate app owners would have no incentive not to have users load apps outside of the secure channel of the official app store, and users would have no incentive to go outside of it. But with the platforms taxing everything inside the app, now every developer has every incentive to say "sideload the unofficial version and get 10% off everything in the app". So the platforms have to make it nearly impossible to keep everything in their controlled channel. Solve the platform tax, solve the side loading issue.
> 2. Having an approved channel for verified app loading is a valuable security tool and greatly reduces the number of malicious apps installed on users devices
I would instead say that having a trustworthy channel for verified app loading is a valuable security tool. F-Droid is such a channel; the Google Play Store is not. So Google is trying to take this valuable security tool away from users.
Yes, I think the end user is in a better position than Google to decide who to trust. Some end users will make bad decisions, but Google's interests are systematically misaligned with theirs.
I'm unclear on why F-Droid is any safer than the playstore and not possibly worse since using it tells potential malware purveyors that you're into sideloading in the first place.
Because F-Droid inspects the source code of the applications they build, removes malware and other antifeatures from them, and compiles them from source to ensure that the binaries they deliver correspond to the source code they've inspected. The Google Play Store doesn't do any of those things. Consequently it's full of malware.
> it seems like a pretty obvious solution is to just have a pop up that has a install at your own risk warning whenever you install something outside of the official app store
That's close enough to how Android already works. Google wants to additionally prohibit installation of apps unless they're signed by a developer registered with (and presumably bannable by) Google.
> Having an approved channel for verified app loading is a valuable security tool and greatly reduces the number of malicious apps installed on users devices
These are claims that Apple and Google make to justify their distribution monopolies, and you are repeating them as fact. I don't think it's true, and cite as evidence both major app stores and the massive amount of malware in them.
Don't parrot anti-competitive lies from monopolists.
> Given that both of these things are obviously true, it seems like a pretty obvious solution is to just have a pop up that has a install at your own risk warning whenever you install something outside of the official app store.
Google already does this. They've always done this, and it has always been a bad thing because it disadvantages app stores that try to compete with Google Play. Imagine you want to sell an app, and your marketing materials need to include instructions on how to enable "side loading" and tell people to ignore the multiple scary popups warning about vague security risks and malware.
> because they take a vig on all transactions done through those apps
This has already been litigated and federal judges ruled that they must allow devs to use third party payment processors. Look up the Epic Games cases against Apple and Google.
> In a normal market there would be no incentive to side load because...
This is nonsense. "sideload" just means to install something outside the Play store. In a normal market, there would be every incentive to do so, as consumers would be able to choose from multiple app stores. Users don't care where an app comes from, as long as they can figure out how to get it.
You know, this would be a fantastic time for Google to get their sandbox in order. If we need to do it like this, go ahead and create a secondary user, call it sandbox and let me install all my wild and unapproved apps there. SecureNet can automatically fail in Sandbox.
But I don't think they're going to do that, ultimately users who actually care about this are an absolute tiny percentage of the market.
And weirdos like us can always just import a Chinese phone that doesn't have mandatory Google verification crap.
> And weirdos like us can always just import a Chinese phone that doesn't have mandatory Google verification crap.
No, we can't. One of the first countries with that mandatory Google verification is Brazil, and we can't import phones which are not certified by ANATEL, they will be rejected by customs in transit.
With elections coming next year, and this being practically a "law" created in partnership with the banks cartel, this may be the time to make some noise about the change.
I knew Brazil was kinda weird with tech import taxes but I didn't know they banned non-certified phones, jezz. Here in Chile they get disconnected from the cell towers after 30 days, but you just need register it^.
Do you know if the Brazilian gov or regulators asked for this first from Google or something?
^: It's less spooky than it sounds, any phone in Chile needs to be compatible with the natural disaster alert system.
The point parent is making, if Google makes it so difficult sharing the software with other people, who is going to make those itch-the-scratch software going through so much trouble?
We would miss out a lot of creative people making software.
There is still a few points of course like being able to modify the base system. Just being able to say, kill the built in facebook is a quality of life improvement.
But it just feels like the benefits of a self owned phone os are going away even when you have it, because everything else changes around it and out from under it, so you don't get the functional benefit from it any more even when you have it.
You give up the use of things like tap to pay (would have been nice a couple times when I forgot my wallet) and drm content, hell, I can't use the stupid LG app that controls an air conditioner, and (increasingly) don't get something else important in return.
Today, there is still some benefit, because this latest change is only just now happening. I can use say, open source password manager and totp apps instead of google authenticator, and can use a pandora client that Pandora absolutely does not approve of, because the author doesn't need anyone's approval to produce the app and there is no choke point that Pandora can petition to block it. Hell why am I even talking about Pandora instead of Youtube and Newpipe? In what universe does Google EVER ratify the developer of Newpipe? (Wait, for that matter, what developer? what if there's an ever-changing fuzzy cloud of 20?) Or full-fat ublock origin...or countless other things whos sole purpose and value is to thwart some will of Googles? Or like the game emulator apps that Nintendo shuts down so aggressively, etc. Those ICE tracking or merely documenting apps. Countless...
Will those various authors still bother putting in the time and effort it takes to make these apps so good when only about 18 people will be able to use them?
I imported a Sony phone to the US because they don't sell it here, and no one else sells a current flagship with a headphone jack and removable sd card and high end cameras.
I successfully found and imported the phone, and got it working on a US carrier. Yay me. It's even rootable! Yay me. Yet I still can't run Lineage on it, because there is probably not a dozen other people like me to be an audience for Lineage on this hardware, and it's too much work to do for no audience.
The fact that today most phones are unrootable means that even if you somehow get around that, you still don't get the benefit because you're such a small audience that no one is producing say LineageOS for example for you.
My individual success bucking the system still did not result in me getting what I want.
I haven't tested it myself, but as far as I know you can run ADB in the phone itself via Termux. Perhaps it's possible to make a wrapper that install apps from F-Droid with ADB? It would mean that you would only need to be tethered to the your PC once.
Obviously they'll eventually remove this because Google is hostile to things like ReVanced / some spook wants this power.
AFAICT it only works on non-rooted devices when used over USB to access another device, because without root it has no access to the adb server on the phone running termux.
I'm definitely not 100% sure about that though, so someone please correct me if not.
Just tested^0, it works with WiFi ADB but it has some limitations.
- The pairing process is kinda awkward, you need to split screen Termux and the Wireless debugging submenu, if you change windows the pairing IP and code are changed.
- The pair survives a reboot and WiFi change. You can disable the 7day revocation, so the pairing process is a one time thing.
- After a pair you still need to connect (adb connect localhost:port) and the port changes after a WiFi change or disconnect. I searched for solutions and apparently it's simple as running nmap twice^1
- It obviously doesn't work without a WiFi connection (unless is there some dark magic to connect your phone to its own hotspot).
So a wrapper seems viable if you are ok only installing apps on trusted networks.
[0]: I'm on GrapheneOS but I believe the dev menu is the same.
As an iOS user who's been frustrated with Apple's approach to "self-loading" (i.e., running your own code on your own devices) and who's actually gone out and gotten Android devices to write PoC/PoV apps on instead, I really don't like Google's stance on this--even if I would not, at this time, choose to daily drive an Android device, I do rely on F-Droid for getting software on six or seven different devices _right now_ and they would be useless to me if I couldn't do it.
This year, I discovered SideStore on iOS, and its wonderful auto-refresh feature. Since then, I have written two iOS apps and am happily using them daily with zero issues. This plus the new Google announcement mean no going back to Android for me any time soon.
Sorry, but "welcome to HN?" Commenters here regularly miss the forest for the trees, ratholing on minutiae and nitpicking one or two words in a 1000 word article. Often totally missing the overall point. We're notorious for it.
That's also a large part of the issue IMO. I currently _have_ root on my rooted and Lineaged Poco F3. But as hardware attestation is becoming the norm I am deeply worried about the future. I have been a pretty eager Android fan due to its achievable-if-savvy openness. If I lose root and sideloading, then Android is dead to me. There would be nothing valuable in it, just another corporate walled garden.
>Regardless, the term “sideload” was coined to insinuate that there is something dark and sinister about the process, as if the user were making an end-run around safeguards that are designed to keep you protected and secure.
I also recall a time in the nascent era of web file hosts, like Rapidshare.de and Mega upload, and some others that came and went so quick that I don't even remember their names, some services offered the option to "sideload" (as opposed to download) straight to their file server.
On MacOS it warns you when you're about to open an app you've downloaded and installed yourself. "Foo has been downloaded from the internet, are you sure you want to open it?". It doesn't stop you from installing it. Why should doing so on your phone be any different?
On the other hand, it used to be very common for malware on Windows to email itself to all your contacts using your real email client. It's probably reasonable for an OS to add a little friction to the process in the modern era, though it probably shouldn't lie and claim the binary is damaged when that's not the problem.
> If i send a golang binary to someone with a mac via signal or other mediums, apple simply displays a dialog that the app is damaged and can't be run.
Has this changed? I thought it failed to launch, but if you go to Privacy & Security in Settings it would give you the option to allow it to run?
Though yes, macOS doesn't prompt you to do that, you have to know where to find it.
I believe they are saying that this update will remove the ability to decide if you want to install it and will require developers to register and pay for their applications to be installable at all. It's been several years since I developed for Mac, but they operated a similar way, secretly marking a file as quarantined and saying "XYZ Is Damaged and Can’t Be Opened. You Should Move It To The Trash" if you didn't pay to play. Maybe this has since changed, or maybe I'm just a dummy. Regardless, whether a platform has any business funneling a user into their walled garden is another philosophical argument altogether.
In my experience the quarantine flag gets added if the file is downloaded via browser, chat program, email, or some other way that isn’t curl/wget/other CLI tool. At least for the past 6-8 months this has been my experience. Not that it excuses anything, but for what I have had to deal with it’s been somewhat helpful.
macOS warns you literally about every downloaded app not from MAS (signed!), unless you build it yourself or remove quarantine manually.
I think it is mostly about expectations, macOS trained people that it is relatively safe to install signed apps. If your app is unsigned, Gatekeeper will refuse to run it.
it also sometimes says `"Foo" Not Opened` `"Apple could not verify “Foo” is free of malware that may harm your Mac or compromise your privacy."` This is frankly pretty insulting to the intelligence of the user and /does/ stop them. I think the paradigm is flowing towards "less" rather than "more"
> Why should doing so on your phone be any different?
Because it's obscenely profitable for the platform holder to have complete control over app distribution.
Can we stop pretending it's about anything else than that? Just imagine if Microsoft got a 30% commission on every PC software purchase in the world...
Why are OEMs like Samsung just letting this happen? A lot of power users who buy flagships will leave for iPhones if Android ceases to be an open platform. (This segment is what is preventing the “green bubbles = poor” narrative from taking over.)
> This segment is what is preventing the “green bubbles = poor” narrative from taking over.
In the US maybe. In Europe, not so much. With Apple having a market share of "only" about one third and WhatsApp being the de facto default messaging app, this discussion never happened here.
Therefore your argument doesn't apply to Europe at all. Android is more than the "hacky" part. Albeit I'd really love to keep that.
Actually sideloading is not a made-up term. It's an existing term, that was (20yrs ago) used regarding to cracks and trainers software. Sideloaders loaded (mainly in DOS but Atari had it too) the main executable along with additional program, a routine or interrupt that would allow disabling of copy protection, cheat on the amount of lives, energy in games (trainers) or simply do something more like play demo music before the game's proper launching. One example - prehistorik game that was distributed by pirates with a "pretrain.com" which allowed to select unlimited lives and sideloaded this routine along with the main program, that would periodically check the counters and keep them up.
-- edit --
Apparently after checking this term in the internet, I am not so sure that this process had been called this way. Maybe I'll leave it here to provoke a correct answer according to the internet rule #1 - to learn what is the correct answer, just post an incorrect answer in the internet and wait
I feel that the root problem is that there aren't enough highly skilled low level developers willing to spend their time writing free software for mobile phones. Why do we have Linux and things around it? Because a lot of very skilled developers decided to work on it and offer it to the world.
The entire App Store system is broken. It should have always been sideloadable apps by default. And app stores for verified app makers. Instead we have Google withholding play store. And now withholding sideloading.
I want to make a report to to US Department of Justice Antitrust Report Online and US Federal Trade Commission: Antitrust Complaint as suggested but I will appreciate some guidance on the wording. Could anyone share a sample?
As a person that tried the Pine64 ecosystem and not being able to will drivers/C++ apps into existence (like I can with web/cross platform), I did not contribute much other than buying the device/doing some videos on YT. (I bought: PP, PPP, PineBook, PineNote, PineTab)
It depended on few people working on it eg. through Discord communities
Anyway point is I saw Expensify I think they have these GitHub PRs which have $ values on them, would be interesting to take that approach, just pay for it literally eg. a GoFundMe for a feature.
Is this seeking Google’s approval for the app? Or is the condition app be signed by a verified user? The latter means side loading is still viable for apps from known developers. This way anyone who is known who may create malware and will not be free from prosecution
Currently it seems that Google is pushing for hardware attestation, so you might be able to install Graphene/Lineage if your phone manufacturer allows you to unlock your bootloader, but many Play Store apps won't work as they'll detect your root. It's actually gotten pretty insane how every low-value app considers themselves the centre of the world and unable to run on a rooted device.
Example: the loyalty card app for a local store chain - there's no money in it, I can just get some discounts when I use it. So an attacker would have to steal my phone, somehow unlock it, and then they can use my loyalty card (btw which is free to obtain for anyone and there are no tiers) to get some discounts. And for that, they have implemented a pretty decent root checker which i had to put in some effort to overcome. And there are many more like it.
You mean Microsoft? No backwards-compatibility with Windows Mobile to begin with (so companies can't reuse their existing investment into line-of-business apps on actually nice modern devices either), then they reset the ecosystem 2 times (once during the WP7->WP8 transition, another time during the Windows 10 transition).
I was a telco product manager at the time and I can tell you right away that it wasn't developers that killed Windows Phone. This book (https://asokan.org/operation-elop/) tells part of the story, but the telcos I worked for (and competed with) definitely played a big role.
I did own a Treo and loved it up to the OG iPhone - I repaired the eff out of it in the hope that something worthy would come along. I kidded myself I would write apps for it. I'd previously played with Simbian tech (and met a very bitter Simbian team dev in London one "eXtreme Tuesday Club" meetup in 2003). I had a Psion Organizer way back and Palm pilot. I thought Palm's WebOS stood a chance. I still own a Ubuntu Phone that I don't use - single script QML apps would have been the killer, but all that's passed now.
You cannot beat them at their own game without some other Goliath like the EU getting involved. The complain and watch strategy doesn't make a difference.
Is the title an intentional mirror of Carver's short story collection "What we talk about when we talk about love"? If so, can someone smarter than me explain what the author means by this connection?
Note that the Android permission system is designed so that you are not in control by design, some permissions are "not for you" and only for "system apps" which you can't control. This gives Google and device manufacturers advantage over third party software developers in the name of security...
I think we should focus on defending the slowly-vanishing ability to unlock the bootloader and fight for the core parts of Android to stay open source.. without these two, installing an APK will mean less and less until it might eventually become synonymous with installing a PWA.
A great example of this is the 'networking' permission. Being able to control which app can speak to the WAN/LAN is a very important security consideration. Instead, every Android app can send any data it wants without the user being able to have a say in the matter. A lot of apps work just fine without being able to 'phone home'.
Thankfully there's the likes of GrapheneOS, however, with Google's recent changes, unless their OEM partner pulls through, their days are likely numbered.
The only reason Google has decided to lock-down Android is because of apps like ICEblock and the ability for anonymous individuals to mass distribute information that governments do not like. Now, they'll be able to hunt you down by requesting Google hand over every ID document that they process. This sets a chilling precedent for free speech. It enables governments to go after those who dare 'speak out' by using platforms to their advantage. You can no longer 'hide in the shadows' and will need to put your entire identity on the line for your morals and convictions.
Of course, if they could do this with Windows, Linux et al they absolutely would. And general purpose computing will, eventually, be closed and locked down, much like what we are seeing with the internet and ID laws. People would have, and did, think such ideas would be unthinkable 10-15 years ago. Yet little-by-little the screws are being ever tightened. The government wishes to tightly control the information flow and decide what is 'best for you' to see. Preferably their chosen propaganda.
Work-arounds that exist today will likely be closed and forbidden in the future. VPNs to bypass age laws, ADB to bypass install-blocks will all be obsolete. You will be required to identify yourself at all times. I half-expect Google to deprecate and remove the concept of VPN's/ADB on Android entirely and laws will be passed to that affect (restricting the apps themselves, or access to the APIs to verified Android devices/Google accounts). If you don't believe me, you only need to see [1] for the direction of travel.
There is little interest from the regulators to stop this. Perhaps the useless CMA will 'investigate' in 5 years time, decide Google perhaps abused its monopoly and then do absolutely nothing because they have no real re-course over an American company. It's likely governments support this position and will not do anything to influence a change of direction.
Eventually, Linux itself will go the same way, people are just waiting for Torvalds to retire from the project to make their moves, but make no mistake, open general-purpose computing is under threat and there is going to be little we can do to reverse the current trends towards closely monitored and controlled computing.
This will most likely be expanded in the future to limit access to certain 'dangerous' APIs like ADB/VPN's etc. This can also be used 'in app' and across the entire OS to shape your experience of what you can see and do. I wouldn't be surprised if 'unlocking bootloader' required an 18+ verified device.
> Regardless, the term “sideload” was coined to insinuate that there is something dark and sinister about the process, as if the user were making an end-run around safeguards that are designed to keep you protected and secure.
This is a conspiracy theory; as there is no evidence that it was deliberately invented to be malicious (it started as a trademark from a company called i-drive). The term almost certainly became popular after the name of the Android Debug Bridge command, `adb sideload`. The adb command naming makes sense considering the phone is plugged into a computer, for installing content externally when the phone could not otherwise "load" the content.
Yes, I think quibbling over the origin of the term and attempts to coin an alternative are a useless distraction. The term emerged organically for good reasons, and doesn't have any negative connotations as far as I'm concerned. Trying to talk about "direct loading" instead is confusing and doesn't even make sense because alternative app stores like F-Droid don't count as "direct loading" under their own definition.
I think defining sideloading as "the transfer of apps from web sources that are not vendor-approved" is a good definition, because "not vendor-approved" is precisely the part I care about. The owner being able to install stuff without Google or anyone else's approval is a good and important capability for every computing device to have.
In any case, I fully agree with the substantive portions of this article. What Google is doing here is a terrible attack on consumer freedom.
While I wont argue about it feeling like a conspiracy theory, I will argue that pretty much no one knows sideloading as a term with regards to what i-drive meant by it.
And the fact that `adb sideload` is where the concept originated does nothing to dispel the way the term is frequently used in a derogatory fashion these days. It's wielded as a bogey man to make people afraid of unsigned applications. Despite the fact that many perfectly signed applications are full of malware and dark patterns.
Also, FFS, this is hacker news. Why on Earth would be arguing in favor of Google locking down how I can install software on my device.
I bought an iphone knowing that Apple has a review process and that I'm limited to apps sold in their store. Similarly, when I had an Android device I knew what I was getting in to.
I appreciate the fairly high level of review that apps get and I completely back Apple's right to control what runs on the OS they developed. Similarly, if _you_ want to run an OS you got from XDA on your Android device and install random stuff, I'll be the last person to stop you.
Hacker news readers are part of the small circle of people who have probably developed a decent intuition for whether software we download is clean or not. Most folks I know do not have this intuition, and many will not bat an eyelash when their new app asks for access to their contacts, etc. Sideload should absolutely continue to be a term that discourages the average person from doing it.
hah, thanks. It's a bit more nuanced than that. Let me try again.
I completely support Apple's right to publish software that makes it difficult for unapproved software to run on it.
Similarly, I support your right to try running something else on it.
Just like my neighbor has the right to publish a browser that makes it difficult to run extensions in it, and I have the right to use a different browser.
Some people would like the phone OS to be regulated like a public utility. I do not support that, and if we _had_ to have it that way, it would be important to have the same standards for everyone and regulate _all_ phone OSes equally. I don't like the thought of what that would do to the chances of any "open" offering.
We should just call it loading. Loading from an app store we can call simply, mortgaging our cognitive liberty and liquidating the middle class for comfort or MOCLALTMCFC.
I realize F-droid has an understandably strong opinion here, but this writing is disingenuous.
From the post:
> Regardless, the term “sideload” was coined to insinuate that there is something dark and sinister about the process, as if the user were making an end-run around safeguards that are designed to keep you protected and secure. But if we reluctantly accept that “sideloading” is a term that has wriggled its way into common parlance, then we should at least use a consistent definition for it. Wikipedia’s summary definition is:
> the transfer of apps from web sources that are not vendor-approved
The opening two sentences of the linked-to Wikipedia page on sideloading:
> Sideloading is the process of transferring files between two local devices, in particular between a personal computer and a mobile device such as a mobile phone, smartphone, PDA, tablet, portable media player or e-reader.
> Sideloading typically refers to media file transfer to a mobile device via USB, Bluetooth, WiFi or by writing to a memory card for insertion into the mobile device, but also applies to the transfer of apps from web sources that are not vendor-approved.
The phrase after the "but" in the second sentence isn't the "summary definition". It's the part of the definition that best supports your argument. Cutting the Wikipedia definition down to that part is deceptive.
Also in the post:
> Regardless, the term “sideload” was coined to insinuate that there is something dark and sinister about the process, as if the user were making an end-run around safeguards that are designed to keep you protected and secure.
Immediately later in the same Wikipedia page is a paragraph that is literally about how the word was coined:
> The term "sideload" was coined in the late 1990s by online storage service i-drive as an alternative means of transferring and storing computer files virtually instead of physically. In 2000, i-drive applied for a trademark on the term. Rather than initiating a traditional file "download" from a website or FTP site to their computer, a user could perform a "sideload" and have the file transferred directly into their personal storage area on the service.
That's funny. The history of how the word was coined and the post's claim about how it was coined aren't similar at all. Weird.
> The phrase after the "but" in the second sentence isn't the "summary definition". It's the part of the definition that best supports your argument. Cutting the Wikipedia definition down to that part is deceptive.
Wat?
Everything after the "but" is what Google means when they use the term sideload and is the only important part of the definition for f-droid's purposes. The other definition is completely irrelevant and, I would argue, hardly ever used anymore.
You argue here that google is technically correct because they’re correctly using sideload.
But that isn’t the point people are angry about. The point is that sideload was a misnomer. Correctly Android users were able to install packages and now cannot. This is anti consumer and breaks the social contract.
Anyway this is so disingenuous that I think it’s astroturf. Here’s the meme we should’ve spreading: Chrome and Android should be broken off from Google. Apple should be forced to allow sideloading, at a minimum, same as any other computer. Phones and tablets should be valid targets for custom OS.
I’m honestly very tired of this argument, everything about it is bad.
Features aren’t rights, if you want a phone that let’s you run whatever you want, buy one or make it yourself.
What you’re trying is to use the force of the state to make mandatory a feature that not only 99% users won’t use, it vastly increases the attack surface for most of them, specially the most vulnerable.
If anyone were trying to create a word that gives a “deviant” feel, they wouldn’t use “sideload”, and most people haven’t even heard the term. There’s a world of difference between words like “pirate”, “crack”, “hack” and “sideload”.
If anything I’d say it’s too nice of a term, since it easily hides for normies the fact that what you’re doing is loading untrusted code, and it’s your responsibility to audit it’s origin or contents (something even lot’s of devs don’t do).
If you want to reverse engineer your devices, all the power to you, but you don’t get to decide how others people’s devices work.
It's a proper argument on its surface, complete with claim, warrant, and impact.
"Features aren't rights"
> see: Consumer Rights.
"Force of the state making sideloading mandatory is bad"
> ...Except we have antitrust laws? The Play Store becomes the only source of apps, all transactions are routed through Google Billing? Not a problem for you?
"99% users won't use"
> Except for when Google demands that transactions happen exclusively through Google Billing, which resulted in the release of the Epic Games Launcher for the world's highest grossing games by download.
"Sideloading is too nice"
> Listen, either it's the case that "sideloading" is a threat to normies or it's not. Are normies your 1% or 99% of users? I thought according to you 99% of users won't sideload.
"You don't get to decide"
> That language ties in pretty well with your fear of the use of the 'force of the state'; that tells me that you support freedom. Great-- you're right, why not let corporations be corporations and do anti-consumer things, they'll be very good to us (while they lobby the state).
> You don’t get to decide how others people’s devices work.
Perfectly reasonable. It's important that people can decide how their devices work for themselves. No one else should decide for them.
But I'm genuinely curious how you see this principle working in practice when there's effectively a duopoly. What's the path for someone who wants to still have any choices for their device? I'm not seeing an obvious answer, but maybe I'm missing something.
`abd install` will still work as per[0] so to me sideloading is still possible, so the statement 'Google’s message that “Sideloading is Not Going Away” is clear, concise, and false' is not correct.
I think users should be able to install whatever software they want, without any charge or other external permissions, but at the same time device and OS makers should be able to make it difficult to do so, within reason. Apparently scam apps are more common in some countries than others and is actually a problem in some countries, although I'm not sure.[1] Google did cite that as the reason for the change.[2] However, combined with the way Google has been locking down Android APIs more and more, (eg. the file system, but other APIs as well) it is concerning. At the same time those changes were also about security. I think every phone should be able to have full root permissions if you go through enough hoops without having to install another ROM. That seems to solve most of the issues here.
So are we going to download APKs from fDroid to our computers and then adb install them to our phones? For every update? I see a lot of people, even developers, giving up.
You can run adb from the phone itself via wireless debugging. From what I understand, you can do this via Shizuku or Termux, and there are apps that can give you a user interface for this. What changes is that users have to enable developer mode to get this, which adds another warning label. Although admittedly they may remove this feature or add more hoops to jump through to use it.
Wireless debugging not only requires an initial setup, but it also requires being connected to a Wi-Fi network to work. Considering the number of Android users in countries where many don't have Wi-Fi, it's not an option for many.
There's also the problem of some banking apps refusing to work if developer tools are enabled.
"adb install" is such a far cry from a normal install that it's laughable to call it an alternative or jumping though hoops "within reason". I imagine it won't allow to update an app without another adb install, for one thing. And controlling adb is even easier for google, so how long till you can "adb install" only from within Android Development Studio and only if you have a verified account? Because otherwise all the spooky skammers would be installing stuff on people's phones willy-nilly!
Author here. I admit I am rather startled by the tone of many comments here and the accusations of disingenuity. Splitting hairs about the origin of the term "sideload" does not change the fact that those who promote the term tend to do so in order to make it feel deviant and hacker-ish. You don't "sideload" software on your Linux, Windows, or macOS computer: you install it.
You have the right to install whatever you want on your computer, regardless of whether that computer is on your desk or in your pocket. That's a hill I'll die on. I'm dismayed to see that this sentiment is not more widespread in this of all communities.
Hey, question. While I'm also miffed about Google's decision and see your point about the term sideloading, there is another elephant in the room you seem to not be addressing here.
You write:
> “Sideloading is Not Going Away” is clear, concise, and false_
But isn't Google saying that you will still be able to sideload via ADB? Which would mean their statement is true, and that your claim that Google's statement is files is itself false?
I'm so confused why you never even mention ADB or its relevance to sideloading, which they refer to rather explicitly in their blog post. At the very least, if you think ADB doesn't change anything, you could mention it and say so. Could you explain this seemingly critical omission?
Forcing ADB may as well be a ban, if you don't see that, you're pretty out of touch with consumers. Sideloading is already hard enough for many, forcing the use of an extra computer, a dev tool in the CLI, and dev mode is way way outside what people will do
The reason for its omission should be obvious. First, most people who "sideload" apps do not have ADB installed, and may not have the technical knowledge to do so. Second, the ability to do so can be taken away just as arbitrarily as the right to do so without it.
Not only will sideloading via ADB continue to work, installing from most other third-party app stores will continue to work. The developers on the Amazon, Samsung, and Epic app stores won't have a hard time with the developer verification process. F-Droid is in a uniquely inconvenient position that they have a legitimate app store, but its design causes them to have a hard time with developer verification.
> won't have a hard time with the developer verification process
Unless any government powerful enough has reason to make Google reject developers. Hell, doesn't even have to be a government. Do anything that annoys Google, goodbye rights for your app to be installed on any Android. Why would you ignore the obvious and main caveat? It doesn't matter what store it "continues to work on". Google can revoke privileges overnight with little to no recourse for the developer, regardless of the merit of such action, the usefulness of the app, or how much people want/need that app. This is literally heading in the direction of Kafkaesque.
I would say the situation is worse as this "subscription-esque" model is "spreading" to areas beyond software. Exercise equipment like ellipticals and bicycles - whose software is/could be borderline +/- resistance level trivial - has been moving to "only works with an online subscription" business models for a long time.
I mean, I have had instances that controlled resistance with like a manual knob, but these new devices won't let you set levels without some $30+/month subscription. It's like the planned obsolescence of the light bulb cartels of the 1920s on steroids.
Personally, I have a hard time believing markets support this kind of stuff past the first exposé. I guess when you don't have many choices or the choices that you do have all bandwagon onto oligopoly/cartel-like activity things, pretty depressing, but stable patterns can emerge.
Heck, maybe someone who knows the history of retail could inform us that it came to software "from business segment XYZ". For example, in high finance for a long-time negotiated charging prices that are a fraction of assets under management is not uncommon. Essentially a "percent tax", or in other words the metaphorical "charging Bill Gates a million dollars for a cheeseburger".
EDIT: @terminalshort elsethread is correct in his analysis that if you remove the ability to have a platform tax, the control issues will revert.
That planned obsolescence thing on light bulbs isn't the entire story. Light bulbs will last longer if driven less hard, due to the lower temperature. But that lower temperature also means much lower efficiency because the blackbody spectrum shifts even further into the infrared. So some compromise had to be picked between having a reasonable amount of light and a reasonable life span.
But yeah agree, this subscription thing is spreading like a cancer.
I'm not an expert on the case law, but supposedly United States v. General Electric Co. et al., 82 F.Supp. 753 (D.N.J. 1949) indicates that whatever design trade-offs might have existed, corporate policy makers were really just trying to screw consumers [1] (which is why they probably had to agree on short lifespans as a cartel rather than just market "this line of bulbs for these preferences" vs. "this other line for other people" -- either as a group or separate vendors). I keep waiting for the other shoe to drop where they figure out how to make LED bulbs crappy enough to need replacement.
EDIT: and, shucks, @kragen beat me to it! :-)
[1] https://en.wikipedia.org/wiki/Phoebus_cartel#cite_ref-USvGE-...
Leds are already awful. I already lost 4 of 10 led light bulbs I boughtast year. I hope they will be replaced. It's because every led bulb has a small transformer inside and it fails quite quickly
I think its a heat dissipation issue. I have some overhead LED lights that replaced some halogen bulbs and they have huge metal heat sinks on the back and have all lasted 10+ years. Unfortunately they are no longer sold but I did buy a few spare just in case.
Interesting, that's been the opposite of my experience.
My Mum converted her homes down lights to LEDs over a decade ago. Hasn't lost a single one.
I moved into my current house 5 years ago, haven't lost a single one either.
I think the quality ranges a lot.
I got one of these free energy audit things which included swapping out up to 30 or so bulbs with LEDs. Whatever contractor did it seems to have gotten the cheapest bulbs they could, and the majority of them have failed by 4 or 5 years later. So far so good on the name brand ones I replaced them with.
Yes, but the compromise didn't have to be an industrywide conspiracy with penalties for manufacturing light bulbs that were too long-lasting and inefficient. But it was. Consumers could have freely chosen short-lived high-efficiency bulbs or long-lived low-efficiency ones.
In fact, they could have chosen the latter just by wiring two lightbulb sockets in series, or in later years putting one on a dimmer.
"resistance level trivial"
Could literally replace the control software with a potentiometer (a resistor)! :)
I mentioned a knob - it did the trick with literal mechanical friction { instead of electrical friction = potentiometer :-) }.
An even more grotesque practice is to charge a stratosphere level premium for the product itself AND put its control behind a subscription e.g. 8sleep
The reason subscriptions are spreading everywhere is that stock markets and private investors usually value recurring revenue at a much higher multiple than non-recurring revenue. The effect can be so large that it can be better to have less recurring revenue than more non-recurring revenue, at least if you are seeking investment or credit.
It creates a powerful incentive to seek recurring revenue wherever possible. Since it affects things like stock prices and executives and sometimes even rank and file employees often have stock, it's an incentive throughout the organization. If something is incentivized you're going to get more of it.
In the past it was structurally hard to do this, but now that everything is online it becomes possible to put a chip in anything and make it a subscription. We are only going to see more and more of this unless either consumers balk en masse or something is done to structurally change the incentives.
This argument, though true, can be simplified to "investors are greedy so you will pay more". And it's really sad and discouraging
All very true and "balk en masse" is what I meant by "first exposé". (Ancient wisdom, even, if you think about individuals and mortages/car loans and having a steady job, etc. rather than just businesses.) Maybe we'll anyway see some market segments succeed with "pay 2x more for your screwdriver, but it will at least be your screwdriver" slogans, and then have screwdrivers to do with what we will, like the proverbial "pound sand". ;-)
I agree with your point about "install" vs "sideload".
> Google’s message that “Sideloading is Not Going Away” is clear, concise, and false
Given your(and my) definition, this statement is false. Google isn't taking away sideloading, you can still use adb. I'd say using adb to load an apk from another device is the proper use of "sideloading".
What Google is doing is much worse, they are taking away your ability to _install_ software.
And yes, HN loves splitting hairs. But if it wasn't for the hairsplitting, there probably would be be much discussion. Just most people agreeing with you and a few folks who would prefer to give up freedom for security.
Hey, I hope you have a nice day. F-droid is one of the communities which was really a key role in, what open source project should I recommend if given the power to, for people to gain maximum impact on, and f-droid was one of the tops in that charts, so much so that I really tinkered with android apps creation with rust/tauri just to create an android app for f-droid (building android apps is hard I must admit, which makes my appreciation for apps on f-droid even more lovely)
> You have the right to install whatever you want on your computer, regardless of whether that computer is on your desk or in your pocket. That's a hill I'll die on
I feel like there are some phones, I will say my honest experience, I had a xiaomi phone which required me to unlock the bootloader for me to root it/ remove the spyware that I feel it has, I never felt safe really (maybe paranoia?) but I wanted an open source operating system on it and that required me to unlock my bootloader
Which required me to create an MI Unlock / MI account which then later required me to open up a windows computer and try to do things with the windows computer
I didn't have a windows computer, I am a linux guy and I didn't want to touch windows and I tried any option available on linux (there was a java thing and some other exploit too but both failed)
Later, I tried to actually install win-boat and tried to install the mi tool in it after so many nights of work and I tried and it actually opened but it asked me for the otp to sign up but I don't know if I overwhelmed their system or not but their OTP just straight up didn't show on the phone's sim I had registered on.
That OTP not coming after 5-6 tries, I am not sure if they had detected it was win-boat or what, but idk, that effectively locks me out of ways to unlock the device and remove some spyware functionality I think it has.
I feel like this case made me feel as if although I had a device, it feels like a license when you think about it. This is true for many other consumer devices as well and thus, people accepting the fact that their devices have become similar to licenses, not hardware which they own, but rather software which they rent
> I'm dismayed to see that this sentiment is not more widespread in this of all communities.
I feel like your message is in the right heart, and its honestly okay, sad even, that some part of the community didn't respond to your message in agreement.
But Honestly, please don't lose hope because of this, You and people/foundations like f-droid,linux etc. inspire a sense of confidence for a good future while actively working on it. I was thinking of trying to host some f-droid mirror but I didn't personally because I was a little skeptical of getting any notices or anything after the f-droid team had created a blog post about something similar.
Also one thing, I would try to tell you is that you are trying your best. And that's all that matters. What doesn't matter is the past or the future or how the community responds but rather doing what you think is right with correct intentions which I think you do a perfect job in.
Doing the right thing can be difficult but maybe in a world where doing the right thing isn't rewarded as much in even mere appreciation or sharing the sentiment whereas doing the wrong thing is financially rewarded. its a complicated world we live in, but hopefully, we all can try to make it a little more beautiful for us and our future generations by trying to do things the right way no matter how hard they are, just because its the right thing.
I may speak these things but I myself regularly contradict these. So I don't feel the best guy speaking this stuff but I just want to say that f-droid really means a lot to me, a recent example is how I ditched that xiaomi phone, used my mum's old moto phone, tried to install termux from playstore but it couldn't download for some reason from play store because it was android 8 yet theoretically it should work, but I then opened up f-droid and installed it from there and I am running a termux/gitea server on it now :)
Please, have a nice day, F-droid/you deserve it, I just hope that you recognize that there are people's lives that you have touched (like my termux thing and there are countless other stories as well) and how impactful the project is.
Lets use this comment as a way to show our appreciation to f-droid in whatever ways it has touched our lives and how effectively google's recent moves are really gonna impact f-droid/ hurt us as well. How I wouldn't have been able to run git server on my phone if it wasn't for f-droid and so much more.
put a fork in it, it's done,almost! android that is. linux phones are comming up fast, and will be set up to run the droid apps we like. but big props to fdroid just used "etchdroid" to transfer a linux iso to a thumb drive and boot a new desk top, and if I get a few bucks ahead I will buy a dev board from these guys https://liberux.net/ flinuxoid?, flinux?
Linux phones are...what? Oh, just like Linux won the desktop. Never mind.
Google really knew what they were doing by hiring Marc Levoy. The Google camera is the only thing keeping me from getting something other than a pixel phone.
I agree it's a pointless distraction, but it's a distraction you instigated by trying to language police your own supporters. I and most others who use the term sideloading don't use it because we want to make sideloading "feel deviant and hacker-ish", we use it because it's the commonly accepted term for installing apps outside the app store. I'm open to alternative phrasing, but "direct install" doesn't work because installing apps from F-Droid isn't a "direct install" and "installing" doesn't work because that doesn't distinguish from installing from the Play Store. "Sideloading" is simply the correct word, and I've yet to see a better alternative. There's no reason to be ashamed of it, or accuse people of being part of some conspiracy for calling it that.
If anything, the fact that Google feels the need to disingenuously argue "sideloading isn't going away" suggests to me that the term sideloading has a good reputation in the public consciousness, not a negative one.
Let's just focus on the fact that Google is trying to take away Android users' ability to install software that Google doesn't approve of, and not stress so much about what words people use to describe that.
Because Google isn't trying to prevent installing, just "sideloading".
This comment is funny because you have defined these words to be as such
You have defined installing to be specifically from play store and sideloading as everything except it.
Google isn't trying to prevent installing, just sideloading works in this sentence because of what you have already defined but you are using this sentence in defense of that....
As OP stated, installing can mean on debian as an example, installing from both apt or either tarballs. Both are valid installations
So it is the same for google/android as well yet google is trying to actively prevent one part of the installing or make it really extremely hard to do so.
It is a dangerous precedent. And I would say that it severely limits what you mean by installing.
I got an PC, and I got internet connection, usually it isn't trying to prevent what I install if I am on linux.
Yet I am on android and earlier it used to do the same but now its a slippery slope where it either requires me to use adb or keep another device at me at all times if I ever want to install software on it.
Not because its not that these phones can't do it, In fact that they already do but they are removing it, simply because they can.
No, that is not the definition I was using. "Sideloading" is a subset of installing, not disjoint from it. If Google were to prevent installing, it would prevent sideloading, but it would also prevent installing from the Play Store, which clearly they don't want.
It's a very dangerous precedent, but one that's difficult to discuss without having a name for the kind of installing that Google is trying to prevent.
If anything, it's the playstore which is a side channel and the website of the software producer the main one.
That's a good point.
I don't know, why do we need a term to distinguish brown from dark orange? The term emerged organically because the built-in app store is the most common way to install apps on mobile phones (and the only way on iOS), but on Android you can also install apps from other sources without needing Google's permission so people came up with a catchy name for that.
It's convenient because now we can say "Google is killing sideloading" as a very succinct way to describe what's happening when we're arguing against it. "Blocking users from installing apps not approved by Google" works equally well but is a bit more wordy. I personally prefer the latter because I think it's a little more precise, but trying to imply people have to phrase things that way or they're part of some conspiracy does nothing but alienate your supporters and distract from the real issue.
> Splitting hairs about the origin of the term "sideload" does not change the fact that those who promote the term tend to do so in order to make it feel deviant and hacker-ish.
That is not a fact, that is your opinion. Lots of people say "sideload" without trying to convey such negative meanings. For better or for worse, the term has entered the common lexicon and I very rarely see it used with negative connotations attached to it.
> Lots of people say "sideload" without trying to convey such negative meanings
Sure, but they effectively do even if they're not trying to. It comes off like you're up to no good or doing something dangerous. Like GP said: deviant.
>Sure, but they effectively do even if they're not trying to.
What specific acts are referring to? Is it just their recent plans to restrict sideloading? This feels circular. "Google is evil because they're trying to restrict sideloading. They're also extra evil because trying to demonize sideloading. How? By restricting sideloading!"
>It comes off like you're up to no good or doing something dangerous. Like GP said: deviant.
Yes, but only insofar as if you're not taking the primary route, you're taking the "side" route. Or you're "deviating" from the intended route. None of that actually implies you're a "deviant" for doing so, any more than a driver taking side streets to shave 30s is a "deviant".
I think the recent push to restrict "sideloading" made people realize that the term itself helps Google frame it to normies as a fringe, non-standard thing that needs controls around it. When in reality you're just installing software on a device.
>I think the recent push to restrict "sideloading" made people realize that the term itself helps Google frame it to normies as a fringe, non-standard thing that needs controls around it.
No, it made all the pro-sideloading people (for lack of a better term) find any reason to hate google even more, including flimsy arguments about how "sidleoad" is some sort of sinister psyop. I still haven't seen any evidence to suggest "sideload" has any negative connotations to the average "normie", beyond its meaning of "install from third party source"[1]. All I've seen are endless speculation that it's a google psyop in techie/hacker[2] circles, like this post.
[1] see also: https://news.ycombinator.com/item?id=45738997
[2] as in "hacker" news
instead of sideload you could use the more correct term "install software on a device you own without permission from Google"
I think the verb "promote" was chosen over "say" here very deliberately
[dead]
[dead]
>Splitting hairs about the origin of the term "sideload" does not change the fact that those who promote the term tend to do so in order to make it feel deviant and hacker-ish.
Can you corroborate this? At least for me, the whole idea that "sideloading" has negative connotations only came up as a result of this debacle, and the only evidence I've seen are some very careful readings of blog posts from Google. The word itself hardly has any negative connotations aside from something like "not primary", which might be argued as negative, but is nonetheless correct.
>You don't "sideload" software on your Linux, Windows, or macOS computer: you install it.
Right, because those devices don't have first party stores. Windows and Mac technically do, as does some Linux distros, but they're sufficiently unpopular that people don't think of them as the primary source to get apps. Contrast this to a typical Android or iOS phone.
> Can you corroborate this?
I don't think this is so much a question of sources & corroboration as it is of language.
Regardless of the origins of the term "sideload", the language implies a non-standard practice. The prefix "side-" may be used in some software contexts to describe normal, non-deviant software, but only in cases where the software in question is considered auxiliary. In general, anything described as "side-*" is connoted to be surplus / additional / non-primary at best - adding that to the term "load" & the loading action itself is surplus/additional/non-primary. It's automatically considered non-standard.
> those devices don't have first party stores
This only supports the argument. If somebody felt an alternative term was required on Android because the first-party store was the primary source of software, the only reason they could have for needing such an alternative term would be to explicitly differentiate that alternative source as unofficial/non-standard.
>Regardless of the origins of the term "sideload", the language implies a non-standard practice.
Because it is non-standard. Like it or not, the intended experience is that you get apps from the play/app store, and for most people that's exactly what they do. This is a descriptive statement, not a normative one. Accepting it doesn't imply you oppose the freedom to run whatever code you want. The language of "sideload" or whatever is directly downstream of this. Just because google is using language that reflects the current state of affairs, doesn't mean they're engaging in some sort of sinister psyop with their word choice, as the OP is trying to imply.
> This is a descriptive statement, not a normative one.
It's both. It's not like "sideloading" is a part of natural language that just happened to evolve this way to describe the practice. The terminology was consciously chosen by the same people who designed the OS to describe it. The people who argue against using this term aren't doing it in some accusatory way, like "you use this term, therefore you're an evil brainwashed minion of the enemy", but rather by using language to not set up their argument on the enemy's terms, no matter how insignificant.
It's like how "jaywalking/jay walking" was popularized - the term itself was pretty crass for the time, the word "jay" conjuring thoughts of some kind of drooling, unintelligent yokel. Back when car infrastructure was still in its infancy, how would you argue that cars shouldn't dominate all streets and cities when the government- and industry-approved name for your action was literally "stupid walking"?
>It's like how "jaywalking/jay walking" was popularized - the term itself was pretty crass for the time, the word "jay" conjuring thoughts of some kind of drooling, unintelligent yokel. Back when car infrastructure was still in its infancy, how would you argue that cars shouldn't dominate all streets and cities when the government- and industry-approved name for your action was literally "stupid walking"?
That makes sense because as you said, "the word "jay" conjuring thoughts of some kind of drooling, unintelligent yokel". The same can't be said for "side", aside from vague accusations that it's not "official" therefore normies think it's bad, but I can't see how you can get away from that accusation without using meaningless phrases like "type 2 install" or whatever (though I'm certain that would get similar amounts of ire for being "second class citizens" or whatever).
Debian has had a "first party store" since the early 90s, and the truth is the diametrical opposite of "they're sufficiently unpopular that people don't think of them as the primary source to get apps". It's been almost the only way I install software (that I didn't write) on my Debian and Ubuntu machines since I moved to Debian. This is true of most Debian and Ubuntu users.
>Debian has had a "first party store" since the early 90s, and the truth is the diametrical opposite of "they're sufficiently unpopular that people don't think of them as the primary source to get apps".
Aren't those all considered first party apps? Sure, debian aren't the authors of nginx or whatever, but they're the people building, packaging it, and adding patches for it. It's a stretch to compare them to the play store or app store.
No, it's not a stretch at all. The user experience is the same, except that Debian and F-Droid apps don't come with antifeatures built in. The only friction is around who to report bugs to.
>No, it's not a stretch at all.
For one, it doesn't contain non-free software, and therefore can't be the primary source of software. Maybe you're a Stallman acolyte who only runs free software, but that's not feasible for the average user.
If you are running Linux non free software in the exception, not the rule. I myself can’t think of any that I run.
The average user might have one or two non-free programs they depend on that aren't websites. Maybe AutoCAD, or Photoshop, or SketchUp, or Excel, or the driver for their oscilloscope, or Dark Souls. Everything else can easily be free software or webapps. So an "app store" that doesn't contain non-free software can be the primary source of software, and for almost all Debian or Ubuntu users, it always has been.
The average Ubuntu user doesn't even have those one or two non-free programs. After all, Autodesk doesn't provide a version of AutoCAD for Linux in the first place.
Apt has supported multiple sources since inception. Debian is not the only supplier.
Right, but those would hardly be considered first party. Just because it goes through apt, doesn't mean it's first party.
> The word itself hardly has any negative connotations aside from something like "not primary", which might be argued as negative, but is nonetheless correct.
Android has an APK installer built in. Opening an APK file launches the installer and installs the application, just like opening an MSI file on Windows launches built-in Microsoft Installer and installs the application.
Google have gradually added impediments to this over this years, such as a requirement to toggle a checkbox in the settings to enable installation, and later some prompts about letting Google scan the package, but calling the system's built-in application installation mechanism "not primary" is absurd.
>but calling the system's built-in application installation mechanism "not primary" is absurd.
So you're arguing that because play store installs and random .apk installs both goes through packageinstaller, the concept of a "primary" install method doesn't exist?
Linux had "stores" long before android
Yeah, and they are the primary way to install software for nearly every distro that has them.
And even when people install software on their user's home only, we don't call it anything different.
It's correct to say that "sideloading" was created to emphasize it's a deviant activity. I believe it was created by the people doing it, when they discovered hacks that enabled them. But I wouldn't be too surprised it was created by the companies trying to prohibit software installation.
>Yeah, and they are the primary way to install software for nearly every distro that has them.
>And even when people install software on their user's home only, we don't call it anything different.
But even on Android the word used is "install". When you try to install an apk, the button says "install", not "sideload". "Sideload" is only used in the context of google's blog post, where it's there to differentiate between installs from first party sources vs others. This is an important distinction to capture, because their new restrictions only apply to the latter, so something like "installing isn't going way" wouldn't make sense. "sideload" captures this distinction, and is far more concise than something "installing from third party sources". Moreover this sort of word policing reeks of ingroup purity tests from the culture wars, eg. "autistic vs person with autism" or whatever.
Personally, the first time I hear that word, it was about video game consoles. Smartphones weren't popular at the time.
The AI says the term sideloading, apart from its origin, was used to describe loading music via USB without iTunes on iPods.
> Right, because those devices don't have first party stores. Windows and Mac technically do, as does some Linux distros
If you find yourself making a statement only to immediately contradict it, consider whether or not that statement is worth making at all.
Plus, I don't see how it is even relevant if a platform has a first party store when it comes to allowing the user to install software.
It doesn't, but that doesn't mean people can't call out disingenuous statements made by the OP. Posts can be directionally correct even if they contain errors, but the errors are still worth calling out.
Maybe you should consider reading a few words beyond the passage you quoted, because the "contradiction" only exists with your selective quoting.
The contradiction exists because you wrote it. If you wanted to avoid having to write a false statement and then walk it back, you could've left it out and skipped straight to explaining why those platforms' first party stores don't count in your estimation. As I recommended.
"Sideloading" definitely has subpar connotations. Something you do which is not the "main approach". Let's be real here.
Exactly
I think we could set the bar substantially higher. Don't even bother with discussion of sideloading. Talk about bounded transactions and device control.
What is needed is: Once I have purchased a device, the transaction is over. I then have 100% control over that device and the hardware maker, the retailer, and the OS maker have a combined 0% control.
First thing on the list for me is dramatically reforming the Digital Millenium Copyright Act (DMCA), which currently makes it a federal felony to provide other people any information or tools they might use to control the devices they own, ex:
> Thanks to DMCA 1201, the creator of an app and a person who wants to use that app on a device that they own cannot transact without Apple's approval. [...] a penalty of a five year prison sentence and a $500,000 fine for a first criminal offense, even if those tools are used to allow rightsholders to share works with their audiences.
https://www.eff.org/deeplinks/2020/09/human-rights-and-tpms-...
_____________
In some ways, I think this is even more important than attempting to bar companies from putting in the anti-consumer digital locks in the first place: It's easier to morally justify, easier to legally formulate, and more likely to politically pass. The average person won't be totally stuck lobbing the government to enforce anti-lock rules for them, consumers can act independently to develop lockpicks.
Plus it removes the corporations' ability to bully people using your tax-dollars and government lawyers.
That bar would require infinitely good software on the hardware. Then it will be your device. Otherwise, they will constantly need to improve it. then it will be their software on your device.
Would you consider Microsoft Windows or Linux as infinitely good software? The scenario described by the GP applies 100% to most personal desktop and laptop computers.
What does this even mean? You don't want software updates? Or strictly only software updates that are 100% aligned with your wishes whatever they may be at the time?
No forced updates, no downgrade prohibition, no bootloader locking, kernel GPL compliance (with drivers that can be loaded in it, even if they are closed source), no remote attestation.
The bare minimum so that I can use the device I bought as I wish, even if the manufacturer later decides to "alter the deal".
> You don't want software updates?
Most of the time, software updates remove features, change things around for no good reason (breaking our workflows), or add unwanted features.
We really should separate pure bugfix updates (which include security updates) from feature updates. We nearly always want the former, but not necessarily the latter.
So much this. I totally want security fixes, but I only want security fixes. I don't want UI changes, features removed or altered, or anything with my usability upset.
My computing devices are tools I use to do my job and run my life. I don't want those tools changing without my consent.
I want it exactly as it is in Linux land. This is a solved problem. How are you so dumbfounded?
I'll take that deal 9 times out of 10. Why would I want updates tied to a phone if I'm going to be installing my own software with its own updates? This is already done on most software, browsers, etc. CVE on text messages? Cool, wasn't using the manufacturer's app anyway.
Unironically, I want finished software. I don't like it one bit how the vast majority of software products today are in an "eternal beta", so to speak.
Android, in particular, is a finished product. It doesn't need yearly updates. It may need an occasional update to patch a vulnerability, but this whole "we changed the notification shade UI for tenth time because we're so out of ideas" thing has to stop.
Maybe software updates could contain things users actually want, that provide a competitive incentive for users to choose to buy the phones from specific makers?
> Or strictly only software updates that are 100% aligned with your wishes whatever they may be at the time?
Um, yes? Constant push-updates are one of the worst tech trends of the last 10-20 years.
Maybe I do, maybe I don't. It's for me to decide what updates I want, if any. Apple and Microsoft do not give you a choice. Precisely zero people wanted Copilot on their computers, but it's there anyway whether you want it or not.
>only software updates that are 100% aligned with your wishes whatever they may be at the time?
wild that you seem to think this is a gotcha question. yes, all the software I want on my devices, and only software I want on my devices
[delayed]
I think this misses the forest for the trees here. The platforms behavior here is a symptom and not the core problem. I think the following are pretty clearly correct:
1. It's your damn phone and you should be able to install whatever the hell you want on it
2. Having an approved channel for verified app loading is a valuable security tool and greatly reduces the number of malicious apps installed on users devices
Given that both of these things are obviously true, it seems like a pretty obvious solution is to just have a pop up that has a install at your own risk warning whenever you install something outside of the official app store. 99.9% of users would never see the warning either because almost all developers would register their apps through the official store.
But there is a reason why Apple/Google won't do that, and it's because they take a vig on all transactions done through those apps (a step so bold for an OS that even MSFT never even dared try in its worst Windows monopoly days). In a normal market there would be no incentive to side load because legitimate app owners would have no incentive not to have users load apps outside of the secure channel of the official app store, and users would have no incentive to go outside of it. But with the platforms taxing everything inside the app, now every developer has every incentive to say "sideload the unofficial version and get 10% off everything in the app". So the platforms have to make it nearly impossible to keep everything in their controlled channel. Solve the platform tax, solve the side loading issue.
> 2. Having an approved channel for verified app loading is a valuable security tool and greatly reduces the number of malicious apps installed on users devices
I would instead say that having a trustworthy channel for verified app loading is a valuable security tool. F-Droid is such a channel; the Google Play Store is not. So Google is trying to take this valuable security tool away from users.
Sure, but you'd probably also agree it should be up to the device owner (end user) which parties are to be considered 'trusted'
Yes, I think the end user is in a better position than Google to decide who to trust. Some end users will make bad decisions, but Google's interests are systematically misaligned with theirs.
I'm unclear on why F-Droid is any safer than the playstore and not possibly worse since using it tells potential malware purveyors that you're into sideloading in the first place.
Because F-Droid inspects the source code of the applications they build, removes malware and other antifeatures from them, and compiles them from source to ensure that the binaries they deliver correspond to the source code they've inspected. The Google Play Store doesn't do any of those things. Consequently it's full of malware.
> it seems like a pretty obvious solution is to just have a pop up that has a install at your own risk warning whenever you install something outside of the official app store
That's close enough to how Android already works. Google wants to additionally prohibit installation of apps unless they're signed by a developer registered with (and presumably bannable by) Google.
I don't trust the Google Play Store.
This comment is very uninformed and misleading.
> Having an approved channel for verified app loading is a valuable security tool and greatly reduces the number of malicious apps installed on users devices
These are claims that Apple and Google make to justify their distribution monopolies, and you are repeating them as fact. I don't think it's true, and cite as evidence both major app stores and the massive amount of malware in them.
Don't parrot anti-competitive lies from monopolists.
> Given that both of these things are obviously true, it seems like a pretty obvious solution is to just have a pop up that has a install at your own risk warning whenever you install something outside of the official app store.
Google already does this. They've always done this, and it has always been a bad thing because it disadvantages app stores that try to compete with Google Play. Imagine you want to sell an app, and your marketing materials need to include instructions on how to enable "side loading" and tell people to ignore the multiple scary popups warning about vague security risks and malware.
> because they take a vig on all transactions done through those apps
This has already been litigated and federal judges ruled that they must allow devs to use third party payment processors. Look up the Epic Games cases against Apple and Google.
> In a normal market there would be no incentive to side load because...
This is nonsense. "sideload" just means to install something outside the Play store. In a normal market, there would be every incentive to do so, as consumers would be able to choose from multiple app stores. Users don't care where an app comes from, as long as they can figure out how to get it.
You know, this would be a fantastic time for Google to get their sandbox in order. If we need to do it like this, go ahead and create a secondary user, call it sandbox and let me install all my wild and unapproved apps there. SecureNet can automatically fail in Sandbox.
But I don't think they're going to do that, ultimately users who actually care about this are an absolute tiny percentage of the market.
And weirdos like us can always just import a Chinese phone that doesn't have mandatory Google verification crap.
> And weirdos like us can always just import a Chinese phone that doesn't have mandatory Google verification crap.
No, we can't. One of the first countries with that mandatory Google verification is Brazil, and we can't import phones which are not certified by ANATEL, they will be rejected by customs in transit.
With elections coming next year, and this being practically a "law" created in partnership with the banks cartel, this may be the time to make some noise about the change.
I knew Brazil was kinda weird with tech import taxes but I didn't know they banned non-certified phones, jezz. Here in Chile they get disconnected from the cell towers after 30 days, but you just need register it^.
Do you know if the Brazilian gov or regulators asked for this first from Google or something?
^: It's less spooky than it sounds, any phone in Chile needs to be compatible with the natural disaster alert system.
Yes, Brazil doesn't allow the commerce of uncertified radio transmitters. It has been like that for close to a century.
If you are asking why the change is happening in Brazil first, the banks cartel met with google and decided to rely on that, for security.
But the purpose of prohibiting sideloading isn't security. It's preventing of apps like NewPipe and Vanced.
But what would be the point when no one would bother writing an app for such a small user base?
So I can test my own apps on my own devices, or upload them to itch for other weird people.
I don't feel like giving Google a large amount of my personal information just so I can distribute free games. Why do they need a copy of my lease ?
The point parent is making, if Google makes it so difficult sharing the software with other people, who is going to make those itch-the-scratch software going through so much trouble?
We would miss out a lot of creative people making software.
Correct.
What I am saying is:
There is still a few points of course like being able to modify the base system. Just being able to say, kill the built in facebook is a quality of life improvement.
But it just feels like the benefits of a self owned phone os are going away even when you have it, because everything else changes around it and out from under it, so you don't get the functional benefit from it any more even when you have it.
You give up the use of things like tap to pay (would have been nice a couple times when I forgot my wallet) and drm content, hell, I can't use the stupid LG app that controls an air conditioner, and (increasingly) don't get something else important in return.
Today, there is still some benefit, because this latest change is only just now happening. I can use say, open source password manager and totp apps instead of google authenticator, and can use a pandora client that Pandora absolutely does not approve of, because the author doesn't need anyone's approval to produce the app and there is no choke point that Pandora can petition to block it. Hell why am I even talking about Pandora instead of Youtube and Newpipe? In what universe does Google EVER ratify the developer of Newpipe? (Wait, for that matter, what developer? what if there's an ever-changing fuzzy cloud of 20?) Or full-fat ublock origin...or countless other things whos sole purpose and value is to thwart some will of Googles? Or like the game emulator apps that Nintendo shuts down so aggressively, etc. Those ICE tracking or merely documenting apps. Countless...
Will those various authors still bother putting in the time and effort it takes to make these apps so good when only about 18 people will be able to use them?
I imported a Sony phone to the US because they don't sell it here, and no one else sells a current flagship with a headphone jack and removable sd card and high end cameras.
I successfully found and imported the phone, and got it working on a US carrier. Yay me. It's even rootable! Yay me. Yet I still can't run Lineage on it, because there is probably not a dozen other people like me to be an audience for Lineage on this hardware, and it's too much work to do for no audience.
The fact that today most phones are unrootable means that even if you somehow get around that, you still don't get the benefit because you're such a small audience that no one is producing say LineageOS for example for you.
My individual success bucking the system still did not result in me getting what I want.
Maybe so I can develop a service without forking over profit to a company that deserves none of it.
I haven't tested it myself, but as far as I know you can run ADB in the phone itself via Termux. Perhaps it's possible to make a wrapper that install apps from F-Droid with ADB? It would mean that you would only need to be tethered to the your PC once.
Obviously they'll eventually remove this because Google is hostile to things like ReVanced / some spook wants this power.
AFAICT it only works on non-rooted devices when used over USB to access another device, because without root it has no access to the adb server on the phone running termux.
I'm definitely not 100% sure about that though, so someone please correct me if not.
Just tested^0, it works with WiFi ADB but it has some limitations.
- The pairing process is kinda awkward, you need to split screen Termux and the Wireless debugging submenu, if you change windows the pairing IP and code are changed.
- The pair survives a reboot and WiFi change. You can disable the 7day revocation, so the pairing process is a one time thing.
- After a pair you still need to connect (adb connect localhost:port) and the port changes after a WiFi change or disconnect. I searched for solutions and apparently it's simple as running nmap twice^1
- It obviously doesn't work without a WiFi connection (unless is there some dark magic to connect your phone to its own hotspot).
So a wrapper seems viable if you are ok only installing apps on trusted networks.
[0]: I'm on GrapheneOS but I believe the dev menu is the same.
[1]: https://www.reddit.com/r/tasker/comments/1dqm8tq/project_sim...
As an iOS user who's been frustrated with Apple's approach to "self-loading" (i.e., running your own code on your own devices) and who's actually gone out and gotten Android devices to write PoC/PoV apps on instead, I really don't like Google's stance on this--even if I would not, at this time, choose to daily drive an Android device, I do rely on F-Droid for getting software on six or seven different devices _right now_ and they would be useless to me if I couldn't do it.
This year, I discovered SideStore on iOS, and its wonderful auto-refresh feature. Since then, I have written two iOS apps and am happily using them daily with zero issues. This plus the new Google announcement mean no going back to Android for me any time soon.
The existing comments here somehow display a big amount of discomfort with the semantics of the article, not so much with the points argued...
Dear F-droid, please edit your article to be technically correct so that HN can like it. All you have to do is change "coined" to "popularized".
Sorry, but "welcome to HN?" Commenters here regularly miss the forest for the trees, ratholing on minutiae and nitpicking one or two words in a 1000 word article. Often totally missing the overall point. We're notorious for it.
Perhaps when you comment on one little thing, its a sign that you agree with the article overall, but have one little nitpick.
The fact that we don't have root access to our phones is insane. This "sideloading" part is just the cherry on top of the dystopia we live in.
That's also a large part of the issue IMO. I currently _have_ root on my rooted and Lineaged Poco F3. But as hardware attestation is becoming the norm I am deeply worried about the future. I have been a pretty eager Android fan due to its achievable-if-savvy openness. If I lose root and sideloading, then Android is dead to me. There would be nothing valuable in it, just another corporate walled garden.
I have no idea what to do when they lock everything up. I just hope my bank app works with a non google phone.
>Regardless, the term “sideload” was coined to insinuate that there is something dark and sinister about the process, as if the user were making an end-run around safeguards that are designed to keep you protected and secure.
I also recall a time in the nascent era of web file hosts, like Rapidshare.de and Mega upload, and some others that came and went so quick that I don't even remember their names, some services offered the option to "sideload" (as opposed to download) straight to their file server.
On MacOS it warns you when you're about to open an app you've downloaded and installed yourself. "Foo has been downloaded from the internet, are you sure you want to open it?". It doesn't stop you from installing it. Why should doing so on your phone be any different?
Depending on your app this is not all.
If i send a golang binary to someone with a mac via signal or other mediums, apple simply displays a dialog that the app is damaged and can't be run.
You need to use chmod to manually remove the quarantine flag to run it.
That for me is something that should be fined ad infinitum, because it is clearly designed to disallow non technical people to run custom apps.
On the other hand, it used to be very common for malware on Windows to email itself to all your contacts using your real email client. It's probably reasonable for an OS to add a little friction to the process in the modern era, though it probably shouldn't lie and claim the binary is damaged when that's not the problem.
> If i send a golang binary to someone with a mac via signal or other mediums, apple simply displays a dialog that the app is damaged and can't be run.
Has this changed? I thought it failed to launch, but if you go to Privacy & Security in Settings it would give you the option to allow it to run?
Though yes, macOS doesn't prompt you to do that, you have to know where to find it.
I believe they are saying that this update will remove the ability to decide if you want to install it and will require developers to register and pay for their applications to be installable at all. It's been several years since I developed for Mac, but they operated a similar way, secretly marking a file as quarantined and saying "XYZ Is Damaged and Can’t Be Opened. You Should Move It To The Trash" if you didn't pay to play. Maybe this has since changed, or maybe I'm just a dummy. Regardless, whether a platform has any business funneling a user into their walled garden is another philosophical argument altogether.
I sure hope they still allow `xattr -r -d com.apple.quarantine /Applications/*`
Quarantine is for any executable downloaded from the Internet. It doesn't prevent it from being opened, it only marks it to be checked for malware.
In my experience the quarantine flag gets added if the file is downloaded via browser, chat program, email, or some other way that isn’t curl/wget/other CLI tool. At least for the past 6-8 months this has been my experience. Not that it excuses anything, but for what I have had to deal with it’s been somewhat helpful.
It definitely adds hurdles to running it.
This is the key and only difference. Scanning is great, and security is great.
but macOS lets you override any system determination, iOS does not, and Google is proposing the iOS flavor.
macOS warns you literally about every downloaded app not from MAS (signed!), unless you build it yourself or remove quarantine manually.
I think it is mostly about expectations, macOS trained people that it is relatively safe to install signed apps. If your app is unsigned, Gatekeeper will refuse to run it.
Do they have to be from the App Store, or "just" notarized?
Notarized works just fine.
it also sometimes says `"Foo" Not Opened` `"Apple could not verify “Foo” is free of malware that may harm your Mac or compromise your privacy."` This is frankly pretty insulting to the intelligence of the user and /does/ stop them. I think the paradigm is flowing towards "less" rather than "more"
> Why should doing so on your phone be any different?
Because it's obscenely profitable for the platform holder to have complete control over app distribution.
Can we stop pretending it's about anything else than that? Just imagine if Microsoft got a 30% commission on every PC software purchase in the world...
Why are OEMs like Samsung just letting this happen? A lot of power users who buy flagships will leave for iPhones if Android ceases to be an open platform. (This segment is what is preventing the “green bubbles = poor” narrative from taking over.)
> This segment is what is preventing the “green bubbles = poor” narrative from taking over.
In the US maybe. In Europe, not so much. With Apple having a market share of "only" about one third and WhatsApp being the de facto default messaging app, this discussion never happened here.
Therefore your argument doesn't apply to Europe at all. Android is more than the "hacky" part. Albeit I'd really love to keep that.
I have never seen people in the EU talk about the bubble colours. Texting is virtually dead in the EU as I know it, it's all in messaging services.
> A lot of power users who buy flagships will leave for iPhones if Android ceases to be an open platform.
99.9% of people who use Android have never, and never will, install apps outside the Play Store, and aren't even aware that they can do so.
Actually sideloading is not a made-up term. It's an existing term, that was (20yrs ago) used regarding to cracks and trainers software. Sideloaders loaded (mainly in DOS but Atari had it too) the main executable along with additional program, a routine or interrupt that would allow disabling of copy protection, cheat on the amount of lives, energy in games (trainers) or simply do something more like play demo music before the game's proper launching. One example - prehistorik game that was distributed by pirates with a "pretrain.com" which allowed to select unlimited lives and sideloaded this routine along with the main program, that would periodically check the counters and keep them up.
-- edit --
Apparently after checking this term in the internet, I am not so sure that this process had been called this way. Maybe I'll leave it here to provoke a correct answer according to the internet rule #1 - to learn what is the correct answer, just post an incorrect answer in the internet and wait
What is to be done?
Install LineageOS or GrapheneOS?
I feel that the root problem is that there aren't enough highly skilled low level developers willing to spend their time writing free software for mobile phones. Why do we have Linux and things around it? Because a lot of very skilled developers decided to work on it and offer it to the world.
Most (some sources say ~80%) Linux contributors are paid by their employer.
The entire App Store system is broken. It should have always been sideloadable apps by default. And app stores for verified app makers. Instead we have Google withholding play store. And now withholding sideloading.
I want to make a report to to US Department of Justice Antitrust Report Online and US Federal Trade Commission: Antitrust Complaint as suggested but I will appreciate some guidance on the wording. Could anyone share a sample?
Tangent about open source development
As a person that tried the Pine64 ecosystem and not being able to will drivers/C++ apps into existence (like I can with web/cross platform), I did not contribute much other than buying the device/doing some videos on YT. (I bought: PP, PPP, PineBook, PineNote, PineTab)
It depended on few people working on it eg. through Discord communities
Anyway point is I saw Expensify I think they have these GitHub PRs which have $ values on them, would be interesting to take that approach, just pay for it literally eg. a GoFundMe for a feature.
ex. https://github.com/Expensify/App/issues/73681
> https://keepandroidopen.org/
The UK petition link appears to be broken:
https://petition.parliament.uk/petitions/744446
The EU page is also no longer accepting new feedback
* https://ec.europa.eu/info/law/better-regulation/have-your-sa...
Right, the period closed:
Feedback: Closed Consultation period 17 July 2025 - 24 October 2025 (midnight Brussels time)
Is this seeking Google’s approval for the app? Or is the condition app be signed by a verified user? The latter means side loading is still viable for apps from known developers. This way anyone who is known who may create malware and will not be free from prosecution
[delayed]
After Google implements this, will I still be able to "side-load" (install any software) on Android-derivative OSes like GrapheneOS?
Currently it seems that Google is pushing for hardware attestation, so you might be able to install Graphene/Lineage if your phone manufacturer allows you to unlock your bootloader, but many Play Store apps won't work as they'll detect your root. It's actually gotten pretty insane how every low-value app considers themselves the centre of the world and unable to run on a rooted device.
Example: the loyalty card app for a local store chain - there's no money in it, I can just get some discounts when I use it. So an attacker would have to steal my phone, somehow unlock it, and then they can use my loyalty card (btw which is free to obtain for anyone and there are no tiers) to get some discounts. And for that, they have implemented a pretty decent root checker which i had to put in some effort to overcome. And there are many more like it.
Yes (but see my comment about the permission system), however, the future of bootloader unlocking and AOSP is uncertain... :(
With one switch, one nasty update (disabling bootloader unlocking on Pixels), Google could kill GrapheneOS..
Everyone developer who worked hard to make windows phone die. Hope you're happy.
> who worked hard to make windows phone die
You mean Microsoft? No backwards-compatibility with Windows Mobile to begin with (so companies can't reuse their existing investment into line-of-business apps on actually nice modern devices either), then they reset the ecosystem 2 times (once during the WP7->WP8 transition, another time during the Windows 10 transition).
Well put. Microsoft following the "Double barrel shotgun, apply one wad per foot." (Reset ecosystem 2 times.)
I was a telco product manager at the time and I can tell you right away that it wasn't developers that killed Windows Phone. This book (https://asokan.org/operation-elop/) tells part of the story, but the telcos I worked for (and competed with) definitely played a big role.
That book is new to me. I wrote https://paulhammant.com/2013/05/07/android-and-the-art-of-wa... on Google vs MSFT and phones before the book. Mine's a perspective that doesn't mention Nokia or its leadership.
I did own a Treo and loved it up to the OG iPhone - I repaired the eff out of it in the hope that something worthy would come along. I kidded myself I would write apps for it. I'd previously played with Simbian tech (and met a very bitter Simbian team dev in London one "eXtreme Tuesday Club" meetup in 2003). I had a Psion Organizer way back and Palm pilot. I thought Palm's WebOS stood a chance. I still own a Ubuntu Phone that I don't use - single script QML apps would have been the killer, but all that's passed now.
Let's not pretend that MSFT would have been one tiny bit better here.
I don't understand this sentence. Can someone rephrase?
You cannot beat them at their own game without some other Goliath like the EU getting involved. The complain and watch strategy doesn't make a difference.
Where do I send my money to fight this?
https://keepandroidopen.org/ is about sending messages, which I have done and will continue to do. But I want to open my wallet.
Is the title an intentional mirror of Carver's short story collection "What we talk about when we talk about love"? If so, can someone smarter than me explain what the author means by this connection?
Perhaps an unintentional one: https://lithub.com/what-we-talk-about-when-we-talk-about-thi...
Note that the Android permission system is designed so that you are not in control by design, some permissions are "not for you" and only for "system apps" which you can't control. This gives Google and device manufacturers advantage over third party software developers in the name of security...
I think we should focus on defending the slowly-vanishing ability to unlock the bootloader and fight for the core parts of Android to stay open source.. without these two, installing an APK will mean less and less until it might eventually become synonymous with installing a PWA.
A great example of this is the 'networking' permission. Being able to control which app can speak to the WAN/LAN is a very important security consideration. Instead, every Android app can send any data it wants without the user being able to have a say in the matter. A lot of apps work just fine without being able to 'phone home'.
Thankfully there's the likes of GrapheneOS, however, with Google's recent changes, unless their OEM partner pulls through, their days are likely numbered.
The only reason Google has decided to lock-down Android is because of apps like ICEblock and the ability for anonymous individuals to mass distribute information that governments do not like. Now, they'll be able to hunt you down by requesting Google hand over every ID document that they process. This sets a chilling precedent for free speech. It enables governments to go after those who dare 'speak out' by using platforms to their advantage. You can no longer 'hide in the shadows' and will need to put your entire identity on the line for your morals and convictions.
Of course, if they could do this with Windows, Linux et al they absolutely would. And general purpose computing will, eventually, be closed and locked down, much like what we are seeing with the internet and ID laws. People would have, and did, think such ideas would be unthinkable 10-15 years ago. Yet little-by-little the screws are being ever tightened. The government wishes to tightly control the information flow and decide what is 'best for you' to see. Preferably their chosen propaganda.
Work-arounds that exist today will likely be closed and forbidden in the future. VPNs to bypass age laws, ADB to bypass install-blocks will all be obsolete. You will be required to identify yourself at all times. I half-expect Google to deprecate and remove the concept of VPN's/ADB on Android entirely and laws will be passed to that affect (restricting the apps themselves, or access to the APIs to verified Android devices/Google accounts). If you don't believe me, you only need to see [1] for the direction of travel.
There is little interest from the regulators to stop this. Perhaps the useless CMA will 'investigate' in 5 years time, decide Google perhaps abused its monopoly and then do absolutely nothing because they have no real re-course over an American company. It's likely governments support this position and will not do anything to influence a change of direction.
Eventually, Linux itself will go the same way, people are just waiting for Torvalds to retire from the project to make their moves, but make no mistake, open general-purpose computing is under threat and there is going to be little we can do to reverse the current trends towards closely monitored and controlled computing.
[1]: https://developer.android.com/google/play/age-signals/overvi...
This will most likely be expanded in the future to limit access to certain 'dangerous' APIs like ADB/VPN's etc. This can also be used 'in app' and across the entire OS to shape your experience of what you can see and do. I wouldn't be surprised if 'unlocking bootloader' required an 18+ verified device.
> Regardless, the term “sideload” was coined to insinuate that there is something dark and sinister about the process, as if the user were making an end-run around safeguards that are designed to keep you protected and secure.
This is a conspiracy theory; as there is no evidence that it was deliberately invented to be malicious (it started as a trademark from a company called i-drive). The term almost certainly became popular after the name of the Android Debug Bridge command, `adb sideload`. The adb command naming makes sense considering the phone is plugged into a computer, for installing content externally when the phone could not otherwise "load" the content.
Yes, I think quibbling over the origin of the term and attempts to coin an alternative are a useless distraction. The term emerged organically for good reasons, and doesn't have any negative connotations as far as I'm concerned. Trying to talk about "direct loading" instead is confusing and doesn't even make sense because alternative app stores like F-Droid don't count as "direct loading" under their own definition.
I think defining sideloading as "the transfer of apps from web sources that are not vendor-approved" is a good definition, because "not vendor-approved" is precisely the part I care about. The owner being able to install stuff without Google or anyone else's approval is a good and important capability for every computing device to have.
In any case, I fully agree with the substantive portions of this article. What Google is doing here is a terrible attack on consumer freedom.
While I wont argue about it feeling like a conspiracy theory, I will argue that pretty much no one knows sideloading as a term with regards to what i-drive meant by it.
And the fact that `adb sideload` is where the concept originated does nothing to dispel the way the term is frequently used in a derogatory fashion these days. It's wielded as a bogey man to make people afraid of unsigned applications. Despite the fact that many perfectly signed applications are full of malware and dark patterns.
Also, FFS, this is hacker news. Why on Earth would be arguing in favor of Google locking down how I can install software on my device.
> Why on Earth would be arguing in favor of Google locking down how I can install software on my device.
They didn't argue for that anywhere in their comment.
I bought an iphone knowing that Apple has a review process and that I'm limited to apps sold in their store. Similarly, when I had an Android device I knew what I was getting in to.
I appreciate the fairly high level of review that apps get and I completely back Apple's right to control what runs on the OS they developed. Similarly, if _you_ want to run an OS you got from XDA on your Android device and install random stuff, I'll be the last person to stop you.
Hacker news readers are part of the small circle of people who have probably developed a decent intuition for whether software we download is clean or not. Most folks I know do not have this intuition, and many will not bat an eyelash when their new app asks for access to their contacts, etc. Sideload should absolutely continue to be a term that discourages the average person from doing it.
> I completely back Apple's right to control what runs on the OS they developed.
Praytell, what right is this?
hah, thanks. It's a bit more nuanced than that. Let me try again.
I completely support Apple's right to publish software that makes it difficult for unapproved software to run on it.
Similarly, I support your right to try running something else on it.
Just like my neighbor has the right to publish a browser that makes it difficult to run extensions in it, and I have the right to use a different browser.
Some people would like the phone OS to be regulated like a public utility. I do not support that, and if we _had_ to have it that way, it would be important to have the same standards for everyone and regulate _all_ phone OSes equally. I don't like the thought of what that would do to the chances of any "open" offering.
We should just call it loading. Loading from an app store we can call simply, mortgaging our cognitive liberty and liquidating the middle class for comfort or MOCLALTMCFC.
I realize F-droid has an understandably strong opinion here, but this writing is disingenuous.
From the post:
> Regardless, the term “sideload” was coined to insinuate that there is something dark and sinister about the process, as if the user were making an end-run around safeguards that are designed to keep you protected and secure. But if we reluctantly accept that “sideloading” is a term that has wriggled its way into common parlance, then we should at least use a consistent definition for it. Wikipedia’s summary definition is:
> the transfer of apps from web sources that are not vendor-approved
The opening two sentences of the linked-to Wikipedia page on sideloading:
> Sideloading is the process of transferring files between two local devices, in particular between a personal computer and a mobile device such as a mobile phone, smartphone, PDA, tablet, portable media player or e-reader.
> Sideloading typically refers to media file transfer to a mobile device via USB, Bluetooth, WiFi or by writing to a memory card for insertion into the mobile device, but also applies to the transfer of apps from web sources that are not vendor-approved.
The phrase after the "but" in the second sentence isn't the "summary definition". It's the part of the definition that best supports your argument. Cutting the Wikipedia definition down to that part is deceptive.
Also in the post:
> Regardless, the term “sideload” was coined to insinuate that there is something dark and sinister about the process, as if the user were making an end-run around safeguards that are designed to keep you protected and secure.
Immediately later in the same Wikipedia page is a paragraph that is literally about how the word was coined:
> The term "sideload" was coined in the late 1990s by online storage service i-drive as an alternative means of transferring and storing computer files virtually instead of physically. In 2000, i-drive applied for a trademark on the term. Rather than initiating a traditional file "download" from a website or FTP site to their computer, a user could perform a "sideload" and have the file transferred directly into their personal storage area on the service.
That's funny. The history of how the word was coined and the post's claim about how it was coined aren't similar at all. Weird.
> The phrase after the "but" in the second sentence isn't the "summary definition". It's the part of the definition that best supports your argument. Cutting the Wikipedia definition down to that part is deceptive.
Wat?
Everything after the "but" is what Google means when they use the term sideload and is the only important part of the definition for f-droid's purposes. The other definition is completely irrelevant and, I would argue, hardly ever used anymore.
You argue here that google is technically correct because they’re correctly using sideload.
But that isn’t the point people are angry about. The point is that sideload was a misnomer. Correctly Android users were able to install packages and now cannot. This is anti consumer and breaks the social contract.
Anyway this is so disingenuous that I think it’s astroturf. Here’s the meme we should’ve spreading: Chrome and Android should be broken off from Google. Apple should be forced to allow sideloading, at a minimum, same as any other computer. Phones and tablets should be valid targets for custom OS.
Maybe they meant coining the usage of "side load" for any non-appstore method of acquiring an app.
Per the original definition, how exactly am I "side loading" if I go to the epic games store and download and install their epic game store APK?
I’m honestly very tired of this argument, everything about it is bad.
Features aren’t rights, if you want a phone that let’s you run whatever you want, buy one or make it yourself.
What you’re trying is to use the force of the state to make mandatory a feature that not only 99% users won’t use, it vastly increases the attack surface for most of them, specially the most vulnerable.
If anyone were trying to create a word that gives a “deviant” feel, they wouldn’t use “sideload”, and most people haven’t even heard the term. There’s a world of difference between words like “pirate”, “crack”, “hack” and “sideload”.
If anything I’d say it’s too nice of a term, since it easily hides for normies the fact that what you’re doing is loading untrusted code, and it’s your responsibility to audit it’s origin or contents (something even lot’s of devs don’t do).
If you want to reverse engineer your devices, all the power to you, but you don’t get to decide how others people’s devices work.
It's a proper argument on its surface, complete with claim, warrant, and impact.
"Features aren't rights" > see: Consumer Rights.
"Force of the state making sideloading mandatory is bad" > ...Except we have antitrust laws? The Play Store becomes the only source of apps, all transactions are routed through Google Billing? Not a problem for you?
"99% users won't use" > Except for when Google demands that transactions happen exclusively through Google Billing, which resulted in the release of the Epic Games Launcher for the world's highest grossing games by download.
"Sideloading is too nice" > Listen, either it's the case that "sideloading" is a threat to normies or it's not. Are normies your 1% or 99% of users? I thought according to you 99% of users won't sideload.
"You don't get to decide" > That language ties in pretty well with your fear of the use of the 'force of the state'; that tells me that you support freedom. Great-- you're right, why not let corporations be corporations and do anti-consumer things, they'll be very good to us (while they lobby the state).
> You don’t get to decide how others people’s devices work.
Perfectly reasonable. It's important that people can decide how their devices work for themselves. No one else should decide for them.
But I'm genuinely curious how you see this principle working in practice when there's effectively a duopoly. What's the path for someone who wants to still have any choices for their device? I'm not seeing an obvious answer, but maybe I'm missing something.
`abd install` will still work as per[0] so to me sideloading is still possible, so the statement 'Google’s message that “Sideloading is Not Going Away” is clear, concise, and false' is not correct.
I think users should be able to install whatever software they want, without any charge or other external permissions, but at the same time device and OS makers should be able to make it difficult to do so, within reason. Apparently scam apps are more common in some countries than others and is actually a problem in some countries, although I'm not sure.[1] Google did cite that as the reason for the change.[2] However, combined with the way Google has been locking down Android APIs more and more, (eg. the file system, but other APIs as well) it is concerning. At the same time those changes were also about security. I think every phone should be able to have full root permissions if you go through enough hoops without having to install another ROM. That seems to solve most of the issues here.
[0] https://android-developers.googleblog.com/2025/09/lets-talk-...
[1] see eg. https://techcrunch.com/2024/02/07/google-starts-blocking-use... at the end of the article for some examples
[2] https://android-developers.googleblog.com/2025/08/elevating-...
So are we going to download APKs from fDroid to our computers and then adb install them to our phones? For every update? I see a lot of people, even developers, giving up.
You can run adb from the phone itself via wireless debugging. From what I understand, you can do this via Shizuku or Termux, and there are apps that can give you a user interface for this. What changes is that users have to enable developer mode to get this, which adds another warning label. Although admittedly they may remove this feature or add more hoops to jump through to use it.
Wireless debugging not only requires an initial setup, but it also requires being connected to a Wi-Fi network to work. Considering the number of Android users in countries where many don't have Wi-Fi, it's not an option for many.
There's also the problem of some banking apps refusing to work if developer tools are enabled.
This actually seems worse from a security perspective to me than allowing installing apps on device.
Your email client from F-Droid has an RCE? Too bad - better hope you update manually!
"adb install" is such a far cry from a normal install that it's laughable to call it an alternative or jumping though hoops "within reason". I imagine it won't allow to update an app without another adb install, for one thing. And controlling adb is even easier for google, so how long till you can "adb install" only from within Android Development Studio and only if you have a verified account? Because otherwise all the spooky skammers would be installing stuff on people's phones willy-nilly!