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.
This is mostly a framing war. Calling it "sideloading" makes it sound risky or unusual, but if we called it "installing software on your own device", Apple's and Google's restrictions would seem absurd - like telling homeowners what kind of light bulbs they're allowed to use.
This community has pockets of people who like authoritarian control, and genuinely believe in Apple or Google Play as some kind of superego that they need to defend, that they believe is protecting us.
This surfaces in many types of discussions, including discussions where they may be prompted to defend the locked down nature of mobile devices.
I say it's just pockets. A vocal pocket. It's not everyone here. But it elicits comments justifying that stuff, which can feel surprising for those who don't share those views.
> This community has pockets of people who like authoritarian control,
Alternatively, we've spent our lives helping our parents out. Last year my mom just got completely owned, total taken over of all her financial accounts. The most likely vector was that her phone was out of date and not receiving security patches anymore.
Luckily her bank's anti fraud systems kicked in before too much damage was done.
Prior to smart phones, many of us remember making monthly, or even weekly, trips to family members houses to remove malware and viruses from personal computers.
It's a great comedy that someone comes along with a "think of my grandma!" appeal to emotion while neglecting that there is no way mom side loaded a virus and it's way more likely they opened Google chrome or some email and clicked one too many links.
You're assuming that the drawbacks of Google's peddled response are worth the alleged fix. Given that the primary malware vector for your mom's phone is the play store, this has all the hallmarks of a nonsolution: no benefit, only drawbacks.
It is the equivalent of restricting car use to paved roads only as a "solution" to car crashes.
> The most likely vector was that her phone was out of date
No one is talking about stopping security patches. Your computer works fine, gets security patches, and you aren't restricted from installing any software on it.
Perhaps, as a fellow developer and a HACKER News user, you can understand that the underlying problem is the device security. Amplifying the problem is the surveillance capitalism ecosystem. Your data is valuable, to the trillion dollar companies and to hackers. Which means they need to collect that data and try to drive a fine line of giving them access but no one else. I thought we were all aware that trying to make backdoors is a foolish endeavor.
> Prior to smart phones ... to remove malware and viruses from personal computers.
Your desktop computer is still a desktop computer. The smart phone didn't change anything there. If you're getting fewer viruses it is because either 1) the user is becoming more proficient, 2) the hackers are becoming less proficient, or 3) (the actual answer) security is getting stronger. Critical to #3 is noting that this has happened without the requirement of app stores.
I also want to stress, the enforcement of app stores is the death of phones and general purpose computers.
What makes computers (phones included) so great is that they are an ecosystem. You can't make a product for everyone, but you can make an ecosystem that can be adapted to anyone. Without programs these things aren't very useful. We're back in the old days like with the IBMs. Just remember, it took Google and Apple years before they put a flashlight app on their phones, but it only took weeks for developers. If we wait for them to build everything we're going to wait forever and won't get half the stuff we need.
>>> 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
That's awful, but it has nothing to do with sideloading or needing locked down phones.
Apparently this idea that security and user control are a trade off has been sold pretty well, and it's bull shit. Nothing about a phone which isn't locked down to the user precludes all the security features you'd want on by default for your mother.
But I doubt you'll catch Apple or Google going out of their way to explain that. They're better off having you believe that the trade off is necessary, and you probably wouldn't miss the freedom anyway.
> This community has pockets of people who like authoritarian control, and genuinely believe in Apple or Google Play as some kind of superego that they need to defend, that they believe is protecting us.
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.
It depends a lot on the bulbs. When we moved into our current house 11 years ago, we replaced everything with LEDs. Many of those original bulbs are still going strong, including all of the 20 or so integrated pot lights we put in to replace the old-school halogen ones. Others died within a year, and replacements have been similarly hit and miss.
To some extent you get what you pay for; most of the random-Chinese-brand LEDs I've picked up off of Amazon have failed pretty quickly. Most of the Philips and similarly expensive ones have lasted. Also the incandescent-looking ones that stuff all the electronics into the base of the bulb tend to fail quickly, as do anything installed in an enclosed overhead light fixture, due to heat buildup.
> as do anything installed in an enclosed overhead light fixture, due to heat buildup
This is my problem. My house has a lot of enclosed overhead light fixtures, and LEDs just do not last long in them. And renovating all of them to be more LED friendly would be quite expensive.
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.
"That planned obsolescence thing on light bulbs isn't the entire story."
Whilst that's certainly true the Phoebus cartel's most negative aspect was that it was a secret organisation, its second was that it was actually a cartel. These disadvantaged both light bulb consumers and any company that wasn't a member of the cartel—a new startup company that wasn't aware of or a member of the cartel would be forced out of business by the cartel's secret unfair competition.
Without the cartel manufacturers could have competed by offering a range of bulbs based on longevity versus life depending on consumers' needs. For example, offering a full brightness/1000h type for normal use and a 70% brightness/2000h one for say in applications where bulbs were awkward to replace (such product differences could even be promoted in advertising).
Nowadays, planned obsolescence is at the heart and core of much manufacturing and manufacturers are more secretive than ever about the techniques they've adopted to achieve their idea of the ideal service lives of their products—lives that optimize profits. This is now a very sophisticated business and takes into account many factors including ensuring their competition's products do not gain a reputation for having a longer service life or better repairability than their own (still a likely corrupting factor that originally drove the formation of the Phoebus cartel).
Right, the philosophy's not changed since Phoebus but the sophistication of its implementation has increased almost beyond recognition. There's not space to detail this adequately here except to say I've some excellent examples from the manufacture of whitegoods and how production has changed over recent decades to manufacturers' advantage often to the detriment of consumers.
In short, planned obsolescence and the secrecy that surrounds it has negative and very significant consequences for both consumers and the environment. When purchasing, consumers are thus unable to make informed decisions about whether to trade off the reduced initial costs of products with a short service live against those that have increased longevity and or improved repairability. Similarly, shortlived products only add to environmental pollution, witness the enormous e-waste problem that currently exists.
As manufacturers won't willingly give up panned obsolescence or secrecy that surrounds it, one solution would be to tax products with artificially shortened service lives. In the absence of manufacturing information governments could statistically determine product tax rates based on observable service lives.
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, but why you buy it then? Everyone should be allowed to price how they want it. If they price at 1m + 100k/month would sell much less. Therefore the price they charge is “reasonable” for correct customers
The fact that Apple and Google have taken away digital freedom on the most important device of our time is shameful and gross.
That they've convinced everyone that this is okay, and that they've maintained regulatory capture to keep doing it, is absurd.
We need web downloads and installs on Apple and Android immediately. With no "scare walls" or deeply nested and hidden menu settings to enable it.
We need the ability to run any kind of tech, including JIT runtimes. Apple and Google shouldn't be able to tell consumers or the industry what type of computing is permissible.
Smartphones are the most important device category in the world. They're how people bank, work, navigate, shop, order, communicate, date, order food at restaurants, take photos, -- life without them is impossible.
It would be nice to see as much competition as we do with the automotive industry, but the next best thing would be to rid Apple and Google of their draconian overlording of the platforms.
Consumers do not have the expertise to articulate this or really understand what is happening to them. This requires regulators and industry professionals to push forward.
> 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 totally agree with that. BUT:
> Splitting hairs about the origin of the term "sideload" does not change
You can't start your article by splitting hairs about the meaning of the term, and then complain that people follow down that discussion :-).
> But how much malware has been distributed via F-Droid versus "Google Play Store"
There's been only a single case of malware that we know of that has slipped into distribution on F-Droid (through a supply-chain attack on a transitive dependency), and it was caught within a day. So if we were feeling glib, we might have made the claim that "there is over 224 times as much malware on the Play Store than on F-Droid".
To me, the question is not even relevant. Whatever the quality of f-droid,each use should be free to decide if they want to use it or not without Google having a life or death choice on the app that you want to use.
The freedom of installing whatever you want indeed brings more opportunity to come across malware, but as long as you lose the freedom, it's up to Google to decide which apps are "safe", which are not. Google will be the only, sole source of apps, they control everything.
It's not about immediate safety, it's about safety in the long run.
Yes, software on F-droid is free and reviewed for anti-features before publishing. Google Play has the worst, ad ridden, dark pattern filled, data guzzling, subscription packed, commercial slop with no real oversight on what gets published. Malware frequently gets on the Play Store, never heard of it being a problem on F-Droid.
I don't even understand how this is an interesting or relevant point. "Can I install what I want on my service how and when I want" is the end of the conversation.
Regardless of its origin, its usage in context clearly implies it's supposed to be understood as a non-standard, non-default process. Making preferred software design choices feel like defaults, or making preferred app or distribution ecosystems feel like default is the product of extraordinary and intentional effort to set expectations, and so I don't see it as an accident that the nomenclature would be used for the purposes you describe.
I did make a comment in this thread about the historical usage of the term sideload, although for my purposes, I was noting a historical quirk frim a unique time in the history of the internet rather than disputing any premise in your post. It was the first and only comment at the time I posted it and I was not anticipating such an unfortunate backlash that seized on terminology for the purpose of disputing your point, or for otherwise missing your point.
But it is indeed missing the point. Requiring developer registration to install is exercising a degree of control over the software ecosystem that's fundamentally out of step with something I regard as a pretty important and fundamental ideal in how software is able to be accessed and used.
FWIW, thank you and the team for all the hard work. Me and my family use it to install, discover, and try out many of the genuinely useful and really cool, high-quality Apps on our de-Googled devices and truly appreciate it. I could never imagine using that ad-ridden, user-tracking, scam-infested, filth-flinging abomination they call Play "Store". The only thing that's worse is GCM - you don't even see it's there as a regular user.
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.
>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.
agreed, but i'm not going to die on any hill. i don't see much point in this discussion, these corps will do whatever they like. for me it is simple: iphone never was an option precisely because of this reason, and i've been quite content with android, but i don't think my current smartphone will run android for much longer, and the next one will definitely not.
it is, but i'm willing to compromise. grapheneos can be an option for a while, ultimately a linux phone. worst case i can settle with 2 phones for a while, one cheap/old stock android exclusively for the bank and such, another one for everything else.
it's also a long run, the way things are shaping up i don't expect alternatives to become mainstream but nevertheless getting improved support over time.
if we indeed end up in a situation where there is no viable alternative then screw that, i might as well go completely off grid.
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
Also if the majority of sideloaders go away because it's become more difficult, what will happen to the development scene? Will it stall out from lack of developer interest because there's such a small audience compared to before? (Despite it still being possible.)
There's no spite or emotion, it's a company. They want to kill NewPipe etc. to force everything through apps they control and can monetize. It's just about money.
A company is a group of individuals acting together for a goal that could not individually be achieved, the legal personality of the company exists to reduce (not eliminate) the liability and coherently steer the members of it. Those shareholders/business partners individually wouldn't be able to earn this much money nor have this much work done by employees of each.
You could make a glossy PC client around it. On the meta quest there's an app called SideQuest that does just that because meta doesn't permit apps to install other apps. It's still a fairly big thing there.
I'm happy about the adb loophole, but I'm worried this would be just the start of the slippery slope, and Google would find a way to lock down adb next, citing the risk of malware sideloaded by fancy tools wrapping adb, once they start popping up.
The number of people that don't even own a general purpose computer is huge. And for those that do, ADB is a ridiculous thing to get setup for a particular device. I get paid to work on android software, and I don't even want to put up with the hassle.
Yes. And a bigger question is, why should I have to? This is a perfectly functional computer, it is more than capable of downloading a file and running it.
It's really sad that Apple and Google (and to some extent MS though they're just behind in this race to the anti-consumer bottom) happened upon this "solution to malware" (note: not a real solution) of "OS vendor vets and controls all software." It's a lazy way, it's an ineffective way, and it has made computers - incredibly flexible, programmable devices - more like cable boxes or telephones from past decades, that you had to rent from a monopolist and had no control over.
As I understand it, the delivery mechanism won't matter: Play Store,ADB, F-Droid, Bluetooth, or website. If the APK isn't signed by a Google-approved developer, it's not going to install.
If there's some ADB command that one can issue to install unsigned APKs for now, it's a temporary reprieve at best. Two Android versions later, the update from Google will read "Only 0.02% of users installed apps using adb, but the corresponding malware incidence rate was 873% more than the Play Store. Due to the outsized risk, we're disabling adb installations going forward"
Not so. The new mandate isn't that all APKs must be uploaded anywhere, only that all APKs must be signed by approved developer keys. So to test new builds, devs will only have to sign with their approved key, then upload. No extra hassle once you already have an approved key.
I'm not sure it works that way. _In general_ before the recent announcement you are supposed to sign the debug build (what you feed into adb to install) with your debug key that's different from the release nor upload key, and the debug key is never submitted to google.
Of course _maybe_ at some point google will also force you to submit your debug key to them. But I don't believe that's the case now.
Sure, you would test-install apps via any delivery method of your choice, including USB-C cable or WiFi, after Google attests that your test-app signature is whitelised[0]. After all, there is no legitimate reason[1] to not sign your app, since you want it to closely match the distributed version as much as possible, and there won't exist unsigned distributable apps.
0. Developer has valid signatures and in Google's good graces, and application hasn't been installed on more than 16 devices
1. Oh, you CI/CD signing infra won't let you? You better fix your workflows to match the Google way.
adb is a developer tool. You need a tethered and trusted computer to be able to transfer an app using adb, and you need to enable "developer mode" on the device, which is an arcane dance that involves navigation through an obscure tree of settings and then quickly tapping a mystery spot 5+ times. Google can't block adb, because that is how Android apps are developed and tested, just how Apple cannot block their developer tools from being able to transfer apps onto an iPhone.
This is so far from a realistic and acceptable substitute that I question the honesty of anyone who claims that "adb will still work, so no problem!"
I hope that explains my seemingly critical omission.
> just how Apple cannot block their developer tools from being able to transfer apps onto an iPhone.
If I recall correctly (I might be wrong, because this was 10+ years ago), but Apple did exactly this when the iPhone was first released. When the iPhone first came out, Apple released its XCode devtools for free, including an iOS emulator that you could use to test your iPhone app. But you had to pay a $99 USD per year "developer program" free in order to use the devtools to test the app on your physical device.
If Google is also blocking preventing you from loading your own software onto your own phone with adb unless you pay a free, then this would be a very important thing to call out explicitly.
You recall correctly, but that did end in 2015, when Apple ended the requirement that developers sign up for their paid developer program to be able to develop and test iPhone apps. I've written about that elsewhere: https://appfair.org/blog/gpl-and-the-app-stores#fn:3
The adb workaround for Android is essentially on par with being able to use Xcode's tooling to install apps on an iPhone: technically possible without paying a fee, but enough friction that no one would seriously consider as an alternative solution for publishing their apps to a general audience.
> The adb workaround for Android is essentially on par with being able to use Xcode's tooling to install apps on an iPhone
The Apple situation is still significantly worse than ADB, because (at least without a paid-for developer account) AFAIK you're limited to a certain number of in-development app that you can install simultaneously and you definitely need to reinstall them every few days. ADB currently has no such restrictions.
Note: Apple restricts apps uploaded with Xcode, (depending on how it is signed I believe) to 7 days or 1 year. adb currently doesn't have this limit.
But what if they find that somebody made 'sideloading' 'too easy' again. E.g. somebody could come up with the idea of running adb or an adb emulator on another phone, or even a small hardware dongle, integrating it with a pretty UI that looks like a regular app shop. Then their currently proposed new rule would become ineffective and due to whatever thought process they arrived at their current conclusion, could place similar limits on adb.
> E.g. somebody could come up with the idea of running adb or an adb emulator on another phone, or even a small hardware dongle, integrating it with a pretty UI that looks like a regular app shop.
That idea already exists and is called Shizuku. You don't even need another phone, because ADB also has a mode for wireless debugging via the network, so you can just use that to locally connect to the ADB daemon running on your own phone.
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.
Perhaps the author is speaking purely from a "consumer" point of view, rather than developer/pro types who of course can bypass restrictions using common dev tools.
I believe f-droid strives to be a simple platform of from-source builds for non-Googled apps that anyone can use.
You will continue to be able to build and run an app even if your identity is not verified. Android Studio is unaffected because deployments performed with adb, which Android Studio uses behind the scenes to push builds to devices, is unaffected. You can continue to develop, debug, and test your app locally by deploying to both emulators and physical devices, just as you do now.
If you see a loophole in the clear argument they're making there, I'd love to know. I don't see any obvious ones.
I'm just not sure people have been referring to that method when saying 'sideloading' and Google didn't mention sideloading specifically there.
This is what they say in the quote this article is about:
"Does this mean sideloading is going away on Android?
Absolutely not. Sideloading is fundamental to Android and it is not going away. Our new developer identity requirements are designed to protect users and developers from bad actors, not to limit choice. We want to make sure that if you download an app, it’s truly from the developer it claims to be published from, regardless of where you get the app. Verified developers will have the same freedom to distribute their apps directly to users through sideloading or through any app store they prefer."
In this paragraph they don't mention ABD at all similar to how in your paragraph they don't mention sideloading.
I see, wow. That's such a frustrating lack of clarity on Google's part and (consequently?) those responding to the blog post...
As far as I now, historically, "sideloading" has always meant "installing from some mechanism other than the Play Store", and everyone has been referring to adb-based installations as "sideloading" as long as I can remember (example [1]). If Google or others don't call using adb sideloading, then I have no idea what they would call it, and I'm thoroughly confused.
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.
F-Droid is also the only one that does reproducible builds which is a big security feature. One that is precisely the cause of making this hard. But it also makes it safer than even the play store. It should really be accommodated.
>But isn't Google saying that you will still be able to sideload via ADB?
No, it will not. Nothing will install an application without a Google approved signature on it. They will remove ad blocks from your Android and you will like it. "The beatings will continue until morale improves" sort of behavior.
I'm hopeful that the mystery OEM that GrapheneOS is targeting is in fact Sony Xperia. If it isn't, I'm just going to stop carrying a smartphone when all my installed apps stop working on it.
> No, it will not. Nothing will install an application without a Google approved signature on it.
How do you interpret this then:
>> You will continue to be able to build and run an app even if your identity is not verified. Android Studio is unaffected because deployments performed with adb, which Android Studio uses behind the scenes to push builds to devices, is unaffected. You can continue to develop, debug, and test your app locally by deploying to both emulators and physical devices, just as you do now.
Isn't that the opposite of what you wrote? What am I missing?
I interpret that as you will be able to install an unverified app. And you will get the annoying unverified app screen every time you launch it. And it will very likely be crippled in other ways, as it is unverified.
>Lando: But that wasn't our deal!
>Vader: I have modified our deal. Pray I do not modify it further.
There is a lot of money to be made in locking down Android and iOS. We should be surprised if companies like Google and Apple are not spreading lies and trying to decieve the public.
No morals can be expected from publically traded companies. Finding a "PR firm" willing to do the lowly dirty job of going on HackerNews, MacRumors or wherever people are and blatantly lie and make stuff up shouldn't be too hard either, I can imagine.
Have to constantly remind others (and myself!) at work that "we aren't focusing on that right now, that's not what this conversation is about". Technical minded people seem to have a real problem of missing the forest for the trees.
> In general HN skews towards an incredibly privileged and spoiled crowd
> This poem sums up most of HN's politics on control structures.
Please let's not have these sweeping generalisations about the HN community or this grandiose "first they came" rhetoric. The HN community is a bell curve like any other large group of people. All the evidence I see from looking at the discussions for hours each day is that it skews left-libertarian - i.e., supports individual freedoms and opposes government and corporate authoritarianism. This is what you would expect from a cohort of people dominated by technology employees and freelancers, of whom most are deeply supportive of the principles of open-source software and the freedom to do what you please with your devices. It also includes huge numbers of people from different places around the world who are not at all "privileged" and "spoiled". Of course there will always be exceptions in a large group of people – or really, the other end of the bell curve. But this broad-strokes characterisation of the HN community as a whole makes no sense at all.
The guidelines ask us to do better than this, in all these different ways:
Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes.
Comments should get more thoughtful and substantive, not less, as a topic gets more divisive.
Please don't fulminate. Please don't sneer, including at the rest of the community.
Eschew flamebait. Avoid generic tangents. Omit internet tropes.
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?
How much does it cost to build a barebones phone that (A) runs tuxracer and (B) makes phone calls? Librem: almost as much as an iPhone. PinePhone: You have to travel to the moon to find one for sale. FLX1: Not for sale yet (so PinePhone 2.0)
Maybe when I can buy a $100 barebones board that I can hook some AA batteries up to and make calls, and develop a little flappy bird clone, people will take notice of the market. As long as every Linux phone is some dude with too much money in his pocket thinking he'll make the next Android, it's not going anywhere. Even with tech nerds.
As far as I'm concerned, it did. Linux is far and away the best OS for my needs so I'll keep using it.
Did it "win" more of some metric of perfusion / capital versus the other big two? Perhaps some, mostly not. Who cares. The market is dumb.
What matters here is whether the capability exists at all. When it comes to phones, I'm still leery about linux. Support isn't quite wide enough and for a device that I need 110% reliability out of we ain't there yet.
I do know one thing - the effects of closed ecosystems that caused 99.99999% of servers to use linux, will eventually come for interface hardware. Companies have periodic bouts of psychosis that make their walled gardens inherently unreliable. It's just a whole lot slower in a realm that doesn't iterate at web-speed. Will that mean everybody uses linux phones in the future? Of course not. But I do hope it will mean I get to put my own phone together with an OS I own, someday. That would be an unequivocal good.
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 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.
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.
This is why this specific definition is problematic: both "sideloading" and "install from Play store" are subsets of "installing".
If one limited the ability to "install from Play store", while keeping the ability to "sideload", would you say it's fair to say "installing is restricted"?
I feel like although sideloading could be correct term maybe but at the same time as the author stated, people might refer something shady to something which is a genuinely normal part, maybe even more safer when you download from f-droid compared to play-store
I feel like you are having this discussion in good faith which is really nice but I just feel like saying that google is oppressing other open source appstores or just using the word installing and later clarifying can make the people feel about how dangerous it really is.
Let me be really clear. If Google can prevent sideloading and the only feasable way for 99% users is their play store which uses their policy terms which can be ever changing, chances are, that they can also prevent people from downloading your app, and can remove your app etc. as well so they can very definitely prevent installing in general as well
The only escape hatch is maybe adb but please, for the 99% of use cases, I doubt how many people would operate a computer open up the terminal and try to use adb or other scenarios, but in all ways, I think that speaking of it as an installing itself isn't so bad after all.
If Google can genuinely go ahead and do this, it would definitely prevent installation of certain app in and in of itself because play store is also controlled by google and they can also remove/prevent apps installs from there too.
I would still recommend to you / the community to say it as an installation as earlier I was also used to saying sideloading but it was only while writing this comment when I realized of how google can actually prevent installation from play store as well since they own it, its an effective lock/restriction in installation itself for all purposes.
Ultimately the only escape hatch is to build hardware that isn't dependent on Google, then stop being dependent on Android, which is what Huawei has done. https://news.ycombinator.com/item?id=45721022 goes into more detail.
I hereby name the thing that Google wants to allow "supplicating an app(lication)". Installing puts software on a device. Supplicating asks Google for an app, and maybe it gets installed.
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.
I think it's better to shut down the project. I used to contribute to privacy projects, but then after being slandered for damaging youtube's "creators" by blocking the trackers, I realize that people enjoy getting f*cked by google and enjoy shilling google collecting personal data. So I stopped, it's better for my mental health and I have more free time for myself.
That's just the price of developing open source software. People will complain. Don't worry about the people who don't want to use your software. They can make their own. You should only consider stopping your own project when there is a better alternative.
> 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.
There's been a concerted effort by smartphone manufacturers to demonize side loading explicitly for some time now. This is actually about code signing rather than sideloading, so it's kind of funny that we have this sub thread that's explicitly about the term sideloading, but regardless, that term has been demonized by Apple.
Is there no line, in your opinion? At this point, there are computers (many of which run variants of Linux in many cases) in my:
1. Laptop
2. Phone
3. Car
4. Washing machine
5. Handheld GPS
6. E-reader
7. TV
Is there some intrinsic different between a device where the manufacturer has programmed it using an ARM/x86-based chip vs a microcontroller vs some other method that means in the 1st case I have the right to install whatever I want? Because that feels like what's happened with cell phones: manufacturers started building them with more capable and powerful components to drive the features they wanted to include, and because those components overlapped what we'd seen in desktop computers, we've decided that we have an intrinsic right to treat them like we historically treated those computers.
For everything on that list, I'd say that if you figure out how to run software of your choice on them the manufacturer shouldn't be able to legally stop you. (And specifically, the anti-circumvention clauses of the DMCA are terrible).
Phones get a lot of attention in this regard because they've replaced a large amount of PC usage, so locking them down has the effect of substantially reducing computing freedom.
> I'd say that if you figure out how to run software of your choice on them the manufacturer shouldn't be able to legally stop you.
That's already the case. The manufacturer can't come after you for anything you do to your device. They can:
1. Set up their terms of service so that things you do to alter the device are grounds for blocking your access to cloud/connected services that they host on their infrastructure
2. Attempt to make it difficult to run software of your choice.
3. Use legal means to combat specific methods of redistributing tools to other people that compromise things they do in number 2.
There is already a widespread notion of "general computing" device.
For all intents and purposes, a laptop computer and a smart phone are one. This is, for example, evidenced by the fact we run general purpose "applications" on them (not defined ahead of time), including a most general app of them all (a web browser).
For other device types you bring up, I would go with a very similar distinction: when you can run an open ended app platform like a browser, why not be able to install non-browser based applications as well? Why require going through a vendor to do that?
"why not" isn't a compelling case for something to be a fundamental right.
I'm not saying I dislike the concept of being able to run my own code on my devices. I love it. I do it on several devices, some of which involve circumventing manufacturer restrictions or controls.
I just don't think that because manufacturers started using the same chips in phones as computers, they magically had new requirements applied to them. Phones had app stores before they were built using the same chips. My watch lets me install apps from an app store.
You've asked for an intrinsic difference between a class of devices: no, you are unlikely to want to run general purpose apps on your washing machine. Yes, you are likely to do so on your smart phone. Probable on your modern "smart TV". Low probability on your eReader.
Legislation like EU Cybersecurity Act hopefully pushes things into more of a fundamental rights thing by demanding that devices don't go into the trash pile as soon as the vendor stops issuing security updates by mandating an ability to keep operating these devices without negatively affecting Internet at large (by, for example, becoming a part of a botnet).
This is already possible with many general compute devices by putting a version of up-to-date GNU/Linux or FreeBSD or... on it. And for a smaller subset of GC smartphones, with AOSP-based Android.
I'm not asking for an intrinsic difference: I'm suggesting that if "I can install custom applications/code on this device I own" is a fundamental right, there would need to be an intrinsic difference. My personal opinion is that there is not an intrinsic difference. That "I want to do it to these devices and not those" can't be the justification for it being a right that I'm able to.
The only one that sounds potentially harmful is the car and in that case I think it should have to meet emissions standards and prove you aren't running a defeat device but like... Yeah. I should be allowed to run my own infotainment system that doesn't crash and doesn't spy on me
I'm not asking what you'd like to do. I'd like to be able to customize all of those things too.
I'm asking why taking a device that uses a microcontroller and making a new model with an ARM chipset and a Linux-based OS seems to suddenly make people treat the ability to install custom software on it as a fundamental right.
Good catch. They are similarly noteworthy to phones: there are all kinds of projects and tools built around making custom and modded games for the Gameboy, or hacking the NES, but there wasn't a movement saying Nintendo was violating our fundamental rights by not allowing users to overwrite or modify the code inside the actual console.
Then consoles started shipping with recognizable internals, and we had waves of people very frustrated at things like Sony's removal of OtherOS, or Nintendo's attempts to squash the exploits that enabled Wii Homebrew.
Yes, you absolutely should have the right to install (or uninstall) whatever software you want on any of those, assuming it contains writable program memory. The alternative is a nightmarish dystopian future where your washing machine company is selling its estimate of your political inclinations, sexual activities, and risk aversion to your car insurance company, your ex-husband, your trade union representative, and your homeowners' association.
I thought I had this line, but I imagined if my credit card had writable program memory, I'd be fine with a third party preventing me from using it for its intended purpose if it wasn't trusted there. There must be some purpose for my own good for preventing me from writing to my own program memory, and I should be able to void this purpose if I deem it worth it.
Likewise, I'd be fine with banking apps on phones requiring some level of trust, but it shouldn't affect how the rest of my phone works so drastically.
Why would your credit card need to act against your interests? The only thing it should be doing is signing transactions to signal that you approve. The credit card company has their own computers that can be consulted to ask them if they approve a transaction. They don't need one in your pocket. They can rent a rack in a data center. It's not that expensive.
Similarly, the banking app on your phone should be representing your interests, 100%. It may need to keep secrets, such as a private transaction signing key, from your bank or from your boyfriend, but not from you. And it definitely should not be collecting information on your phone against your will or without your knowledge. But that is currently common practice.
My washing machine could be programmed to do all of those things you're worried about without any writeable memory. Why does the parts the manufacturer puts into it turn it from an appliance that washes my clothes to a computer that I have a right to install custom code on?
The principle is that the owner should have full control of their own device, because that's what defines private property. In particular, everything that the maker can make the device do must be something that the owner can make the device do. If the device is simply incapable of doing a certain thing, that might be bad for the owner, but it's not an abrogation of their right to their own property, and it doesn't create an ongoing opportunity for exploitation by the maker.
Maybe in theory your washing machine could be programmed to do those things without writable program memory. Like, if you fabricated custom large ROM chips with the malicious code? And custom Harvard-architecture microcontrollers with separate off-chip program and data buses? But then the functionality would be in theory detectable at purchase time (unlike, for example, Samsung's new advertising functionality: https://news.ycombinator.com/item?id=45737338) and you could avoid it by buying an older model that didn't have the malicious code. This would greatly reduce the maker's incentives to incorporate such features, even if it were possible. In practice, I don't think you could implement those features at all without writable program memory, even with the custom silicon designs I've posited here.
If you insist that manufacturers must not prevent owners from changing the code on their devices, you're insisting that they must not use any ROM, for any purpose, including things like the PLA that the 6502 used to decode instructions. It's far more viable, and probably sufficient, to insist that owners must be able to change any code on their devices that manufacturers could change.
>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).
Well, yeah, it's not nearly as extreme, companies have become much better at PR. Still, the insinuations of something being unofficial, unrecognized, unsecured, really half-unintended still paint a picture of how Google wants its software to be seen. Like, I have no doubts that if Microsoft decided to start locking down Windows PCs to the Microsoft Store (the "intended experience" that they probably already imagine for their model customers), the temporary bypass will be accompanied with a prompt like "DANGEROUS: Are you sure you want to enable Unsecured Mode? (Y/N)"
> the intended experience is that you get apps from the play/app store
Once again, this is the point.
> it doesn't imply you oppose the freedom to run whatever code you want
But it does.
Let's first look at what's good about "intended experience" & possible legitimate reasons to have a differentiation between "vendor-approved" 3rd-party apps & non-"vendor-approved" 3rd-party apps.
The connotation of an "intended experience" is that the experience is supported by the OS vendor. If you have issues with your experience, these are issues that can be reported & the OS vendor will endeavor to fix. Leaving aside the fact that Google has no user support to speak of, even if they did, this isn't something they would every offer for 3rd-party Play Store apps regardless. So 3rd-party Play Store apps are not doing anything for users to provide them with an "intended experience" that isn't equally available sideloading.
The only other legitimate reason to have a differentiation would be to ensure the user doesn't install malware. Play Protect currently does this with sideloaded apps, so once again there is no difference in the "intended experience" from the user's perspective.
If there are no legitimate reasons to differentiate the experiences, the only reasonable conclusion remaining is that they're differentiates to dissuade user freedom.
>Let's first look at what's good about "intended experience" & possible legitimate reasons to have a differentiation between "vendor-approved" 3rd-party apps & non-"vendor-approved" 3rd-party apps.
It's pretty obvious that they think the distinction is worth having because they can vet apps they signed, rather than random apks from the internet. You might think that's a flimsy justification, but that's not a reason to reject such a distinction exists at all.
>The only other legitimate reason to have a differentiation would be to ensure the user doesn't install malware. Play Protect currently does this with sideloaded apps, so once again there is no difference in the "intended experience" from the user's perspective.
That's purely reactive (you can't scan for stuff that you don't know about), and doesn't ensure identity validation. Again, you can argue how good those reasons are, but there's at least a plausible justification for it.
>The connotation of an "intended experience" is that the experience is supported by the OS vendor. If you have issues with your experience, these are issues that can be reported & the OS vendor will endeavor to fix.
When was the last time anyone got "support" for Android/iOS from Google/Apple? At best you have random forums that google/apple staff check once in a blue moon, if you're lucky.
> It's pretty obvious that they think the distinction is worth having because they can vet apps they signed
This is an assumption made in exceptionally generous good faith. It's certainly possible, but I would argue this is far from obvious, & there's enough circumstantial evidence to support this being completely untrue.
Sure, Google can vet apps they sign. Whether having this ability is their primary motivation for having a distinction (or whether they will actually vet apps they sign) is a very different question.
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.
It only goes through "apt the program", but apt is just serving as a method of installing a package, which is hosted on one of the configured apt sources.
Calling all software installed through apt "first party" is a wild stretch, since you can apply the same logic to git, wget, or a web browser. For instance, it would probably be correct to say that most Windows software is downloaded and installed through Chrome, but nobody in their right mind would claim Google owns the largest first party store for Windows.
So is Debian the first party? Or the clone hosted by a university near you? You probably had a mirror there, not Debian's own host. Because they used to be the slowest.
> 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?
If we're using "primary" to mean "first-party" (as in your original comment), then the system's built-in package installer is the most first-party of all, so it's definitely not "not primary".
If we're using "primary" to mean something like "most popular", then I don't see how the term "sideloading" would make any sense to describe "not primary". Are we side-commenting here, and side-submitting HTTP requests, because we're not posting to Facebook, the primary website?
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.
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.