Posted by rom1v 16 hours ago
People who realized they actually owned the thing they bought wanted to do what they wanted, which required circumventing Apple's control or "jailbreaking". This differentiator stimulated Google to "allow" installing on Android without "jailbreaking" the device aka "sideloading", giving the illusion of the kind of freedom that was never in question on normal computers.
It is interesting though how this same conversation doesn't exist in the same way in other areas of computing like video game consoles or other embedded computing devices where the controls against arbitrary applications is even stronger.
The fact that mobile phones aren't yet just a standard type of portable computer with an open-ish harware/driver ecosystem that anybody can just make an OS for (and hence allow anybody to just install what they want) is kind of wild IMHO. Why hasn't the kind of ferver that created Linux driven engineers to fix their phones? Is Android and iOS just good enough to keep us complacent and trapped forever? I can't help but think there might be some effect here that's locking us all in similar to how the U.S. healthcare system can't seem to shake for profit insurance.
I'm sometimes surprised at the plethora of cheap handheld gaming systems coming out of China that support either Linux, Android, or sometimes both, and seem to be based on a handful of chipsets. If anybody ever slapped an LTE module and drivers onto one of those things we'd have criminally cheap and powerful, open phone ecosystem.
Historically, when the first game consoles with game cartridges existed, the hardware was much more niche than the available personal computers. Game system developers designed hardware specifically for games, and game developers developed for those specific systems. Also, physical media for games provided an ownership model and DRM.
In 2003, Apple released the iTunes Music Store partnering with music labels to counteract the prevalence of music pirating. That was the first major digital marketplace with DRM and way before the App Store in 2008!
In 2005, digital distribution for video game consoles came with the Xbox 360, PlayStation 2, and Wii. Being game consoles with unique hardware, they kept their restricted licensed development model of previous generations.
The iPhone and App Store just followed that pattern. Unique hardware and a licensed digital marketplace to go with it.
Now, the hardware between video game consoles, smartphones, and personal computers are mostly unified; and the only real difference is software, but the restricted marketplace model still remains.
---
> The fact that mobile phones aren't yet just a standard type of portable computer with an open-ish harware/driver ecosystem that anybody can just make an OS for (and hence allow anybody to just install what they want) is kind of wild IMHO. Why hasn't the kind of ferver that created Linux driven engineers to fix their phones?
DRM. There are already devices where you can unlock the bootloader and install any OS on it. But then you won't be able to install apps that use the Play Integrity API to ensure DRM. Companies/developers want revenue and develop apps that require Play Integrity.
Any device that doesn't have DRM will never support a paid digital marketplace or paid content streaming.
> Is Android and iOS just good enough to keep us complacent and trapped forever?
Probably. Microsoft tried a DRM supported OS with Windows Phone and that failed.
---
That being said, digital marketplaces and DRM have there place to prevent piracy and allow developers and creators to make a living.
If someone has a solution to prevent piracy without a root of trust that would be ideal.
Or at least ten years earlier with a Japanese SNES:
If someone has a solution to prevent piracy without a root of trust that would be ideal.'
This is the equivalent statement to inspecting everyone's bag at any point because they might have something illegal. It's not an acceptable move from google.
and that someone is named Gaben, and the solution is called Steam. He has done more to solve piracy than any media empire who proportedly spent billions in law suits, lobbying and anti-circumvention ever did.
It used to be via hardware in the disc reader, then online license checking. And now it's fully digital, media and license.
The fucked up part is the fact that we can't transfer digital ownership of purchases. But at least I can use my purchases across multiple devices. Maybe this is what we should use blockchains for, but it would still require a locked device with root-of-trust.
---
> It's not an acceptable move from google.
By all means, you can have an unlocked Android device with a non-Google sanctioned OS and not use Google Play. That way you can use any app that doesn't require Google Play Protect.
Companies are OK with it because it makes them money. The majority of users are OK with it because they can use those companies' apps.
Yet here am on linux buying games on steam
If anything, I would bet on a shift where Steam on Linux requires a signed OS like Windows Secure Boot. Call of Duty and Battlefield 6 already require Windows Secure Boot.
Wait, a signed Linux OS with Secure Boot already exists. It's Android Play Protect.
Also on Linux, you only get Widevine L3, which limits video and audio quality for DRM web content.
The people pushing for drastic technical measures to "prevent pirating" are probably accountants, that have no other idea of how to generate value and they imagine all "pirated content" will be converted to paid - which is not the case.
Without any sort of DRM and today's internet speeds, pirating digital media would probably be like Napster
Greenheart Games famously purposely released a different version of Game Dev Tycoon for pirating. You can read the blog post here: https://www.greenheartgames.com/2013/04/29/what-happens-when...
None of the attestation stuff actually works for that.
For streamed content the pirates only need one person to crack one device and then everything is on The Pirate Bay. Notice that it's all still available in such places despite the DRM and the people still paying for it are still paying for it despite its availability there.
And apps are the same. If you put some attestation in your app, the pirates would just disable it in the copy they distribute, because attestation does nothing to prevent copying.
What it's nominally supposed to be for is so that a server can verify that the device is approved before providing some service. But that only works if a) the thing the server is providing is individualized rather than generally available, and b) the attacker can't get an approved device. The first is what makes it useless for copy protection. The second is what makes it useless for e.g. a bank app, because the attacker will just steal the user's credentials on a compromised device that never even attempts attestation because it's only connecting to the attacker's servers, and then put the stolen credentials into an approved device in order to transfer the money.
The only party to benefit from any of this is the incumbent platform if they can fool useful idiots into using it in order to lock customers into their platform.
Thus the push for locked devices.
> What it's nominally supposed to be for is so that a server can verify that the device is approved before providing some service.
Which is why Neflix wont work with a device failing Play Protect.
> The first is what makes it useless for copy protection
Not if you require a locked device to download the artifact in the first place to prevent copying.
> Which is why Neflix wont work with a device failing Play Protect.
And yet the pirates still have all of their content, because DRM doesn't work. One pirate cracks one locked device and can download their entire catalog with it. That one pirate needs to know something about computer security and side channel attacks etc., but none of the people downloading it do.
It can't prevent the first copy from being made because the devices are only secure against amateurs but not professionals, and it can't prevent any of the subsequent copies because the pirates aren't using any DRM to distribute them.
I know and I'm saying what we are seeing is a push to plug all those holes. iOS, Android, macOS SIP, Windows Secure Boot. All root-of-trust systems, so that only operating systems that prevent copying can download it in the first place.
Those pirates aren't using locked devices to copy content. They are using devices lacking copy protection.
There is no way, you can plug all holes, iPhone couldn't do it with their golden cage and they spend ridiculous amount of money so their phone cannot be rooted, but you still have rooted iphone.
Yup. The Amish have had no trouble implementing a single payer healthcare system in the USA. It can be done, where the people want it. But, by and large, the people really don't care. In the back of their minds they might think it would be nice to have in the same way they think it would be nice to have a muscly six pack, but when it comes down to putting in the effort to see it happen...
Yes, the people could care more and could stand up for it, but it's so easy to blame them and that's exactly what the corporations & politicians want.
It's not the "corporations"[1] keeping you from that six pack, nor it is it keeping you from building a single payer healthcare system. Not wanting to put in the toil to make it happen will certainly get in the way, though. We all understand why nobody really wants to put in the hard work and suffering to make the necessary changes, but that doesn't change the fact that it won't happen until you do it.
[1] Which, in this context, is just another way to say people. And in this case often the very same people. ~40% of US corporate stock is held by Average Joe retirements savings account (IRA, 401k, etc.). Ask these people if they'd like a single payer healthcare system and the answer would almost certainly be "Yes!". But if you then ask them to do the work to see it through: "Never mind. What we have will do.".
No, I think its referring more to the systems that describe how the group of people behave. It is an important distinction.
Also, the idea that effective and lasting change requires significant personal sacrifice and enduring hardship is yet another thing that corporations and politicians would like you to believe. It's great for causing inaction through human nature. Its effectiveness can be seen in anti-riot measures like tear gas or less-certainly-lethal munitions, asking people the question of "do you believe enough to endure THIS?" It's a rhetorical question.
Yes, there needs to be a lot more uproar for these cases as well. One of the most appalling cases is that of macOS. To distribute your app (as a .dmg for instance), you need to sign up and pay for a Developer ID, sign the app with a Developer ID certificate and then notarize it, EVEN if you don't intend to use their App Store.
If you want to sign using a cert trusted by apple, and distribute on their infrastructure, you do need a paid account.
This seems like a reasonable compromise, quite honestly. That is based on remembering the bad old days of just having to trust that the software you downloaded from some random shareware site hadn't been modified maliciously.
Users will just assume the app is broken, a virus or that you're a hacker, all because of the way macOS treats apps from developers who didn't pay the Apple tax or submit the app to Apple's panopticon for approval.
Users should not have to know some cursed and arcane ritual to run the apps they want to run.
However, any attempt by Apple to scare vs. just inform/confirm would be a dark pattern we don’t need.
(Might be quicker for some in Terminal if supported.)
I think it used to be Right Click > Open, then confirm.
This is part proprietary pedigree too.
You had to buy Nintendo cartridges to play Nintendo games, so no one ever questioned the Nintendo seal.
I obviously can't speak for all "Linux driven engineers", but only about myself, as someone who's daily driven linux for a long time and who enjoys tinkering with computers.
I consider phones in the same category as a gaming console: a "single purpose" device.
I find they're not practical for much more than mindless scrolling and the occasional text (and even that's a pain, to the point I usually do it from my computer). I just hate staring at a tiny screen and obscuring half of it with my hand when I need to interact with it.
I'm all for geeking out on things, and love to tinker. But the phones are simply not attractive to me. I used to have Android phones with custom roms, but that was only because samsung had atrocious support for older devices. My current iphone is supported until it can't be used anymore and does everything I need.
Whenever I get the itch to tinker, I'll do it on a computer with a full keyboard and big screen.
> Is Android and iOS just good enough to keep us complacent and trapped forever?
I think they are, especially since us "linux driven engineers" are a tiny fraction of the market. Basically nobody but us cares about these things. Just like almost nobody wants a small phone, or thick phone. Even with regular computers, most people didn't tinker, they would just install a few programs, which would have been on an hypothetical app store anyway.
It's because each phone SoC is essentially its own bespoke architecture. You can't build one arm64 Linux ISO that will work on all phones like you can an x86_64 ISO on a PC. Each and every model of phone requires 0) unlocked bootloaders and either 1) full support from the vendor for Linux or 2) dedicated hackers willing to reverse engineer the board to get it to boot Linux in the first place & then developers willing to write missing device drivers & then maintainers willing to keep the fork up to date or mainline the changes.
It will always be cheaper for phone manufacturers to develop bespoke SoCs than it is for them to implement protocols and interfaces that make booting and hardware discovery standardized like they are on the PC. Making a phone as accessible as a PC to booting generic operating systems inherently means increasing costs at every level from the design up.
> I'm sometimes surprised at the plethora of cheap handheld gaming systems coming out of China that support either Linux, Android, or sometimes both, and seem to be based on a handful of chipsets. If anybody ever slapped an LTE module and drivers onto one of those things we'd have criminally cheap and powerful, open phone ecosystem.
On the surface it seems like that, but all of those devices suffer from the same issues I described above. There will be thousands of devices that "support" Linux, but only nominally.
What happens is, if the manufacturer even releases the kernel source, you get a git dump of a forked kernel that was never modified to be upstreamed with the vanilla mainline kernel. That essentially means you are stuck using that fork unless you have the time, knowledge and skill to port that fork over to the mainline, which is a lot of work. This applies to every SoC, and SoC modification, in gaming systems. Barely any of this work crosses over or can be standardized like it is on a PC.
None of that makes a platform a real open ecosystem.
Source: I'm involved in porting and maintaining a Linux distro for those cheap Chinese handheld gaming systems. The only reason Linux runs on them is because weird nerds spent time getting it to run on them. When they get bored, your Linux "support" ends.
The best we can hope for is for ARM servers to scale down to the point we can use them in small form factors, as ARM servers implement the same standards PCs do to run generic Linux ISOs. We aren't going to get this from the mobile hardware ecosystem, there just are no incentives to make such an investment. Maybe we'll get them if ARM PCs truly take off.
> It is interesting though how this same conversation doesn't exist in the same way in other areas of computing like video game consoles or other embedded computing devices where the controls against arbitrary applications is even stronger.
The conversation takes place all the time, there are tons of people who want to, and do, run homebrew and Linux on their consoles, same thing with embedded devices. Getting Linux or Doom to run on an embedded device is a rite of passage.
Linux is the answer though on mobile it’s just starting to be a little competitive.
“Steve Ballmer: We said ooh, IBM's probably not going to like this. This is going to threaten OS 2. Now we told them about it, right away we told them about it, but we still did it. They didn't like it, we told em about it, we told em about it, we offered to licence it to em.
Bill Gates: We always thought the best thing to do is to try and combine IBM promoting the software with us doing the engineering. And so it was only when they broke off communication and decided to go their own way that we thought, okay, we're on our own, and that was definitely very, very scary.”
Right, but that's a choice from manufacturers, not a requirement of building a mobile platform.
> It will always be cheaper for phone manufacturers to develop bespoke SoCs than it is for them to implement protocols and interfaces that make booting and hardware discovery standardized like they are on the PC.
This... seems suspect? I'm not doubting you, but I do wonder if it's a question of robbing Peter to pay Paul; perhaps it is cheaper to design a bespoke chip than it is to develop a standard for it, but over the course of many generations the benefits of standardizing would kick in?
I do know that RISC-V can support UEFI, so perhaps that's where we need to look to see how developments work out in the long run.
Yup, it's a cost thing.
Standardizing busses, protocols, discovery etc is costly, it adds a cost to every SoC, just wiring up components on PCBs is quick, cheap and takes up less space. All three are important in mobile.
The reason you'd implement the standards is for interoperability, which is not what mobile devices are going for. You're getting the OS the manufacturer chooses and that's it, the hardware doesn't have to support anything else.
Standards are also a commitment, and that commitment can be a cost in the future. It's not free for PCs to support all of the legacy hardware they do, for example. A lot of work goes into that.
The reason I bring up ARM servers and PCs is because both have a long legacy of standardization, and to be a real player in either space, you need to meet those expected standards, which ARM ISAs have. Mobile has no such legacy. If PCs had no such legacy, I think we'd see the same issues mobile does today (which we kind of already do on tablets, Chromebooks, etc).
It is worth mentioning that the push against open phones never came from big tech but from governments everywhere in the world. Tightly controlled communications was and still is the status quo. People sometimes forget that e.g. in Germany telecommunication used to be a government authority and it was prohibited by penal law to even open a telephone. Things like weak encryption standards and tightly closed down proprietary communication chips inside phones were always intentional.
None of this justifies or explains Google's actions but it puts things into perspective. Personal computing is an outlier, and if home computers had been connected to a network from the start they would probably have been as tightly controlled as all other communication devices have always been.
Unfortunately, the control authorities still exist and seek to gain more power over computing devices and their goals mostly align with the commercial interests of large tech companies, who have basically just become alternative telco providers. So, I estimate that personal computing will be more or less eradicated relatively soon.
Far less technical people from my perspective
Not fun if you work I.T. whatever you role is
It wouldn't, you need drivers for your modem, gpu, gps etc. It's encumbered with patents and "prohibited" software circumvention techniques, you're right about one thing it would be regarded as criminally offensive by our current legal system.
Speaking of android, if iOS had jailbreaking, maybe we need a bigger prisonbreaking from Google
Yeah. It's called capitalism, where the reasoning behind everything is "How can businesses make a profit?". And in the U.S., it's also, if the business doesn't make a profit I'll starve.
Such phones exist:
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.
> 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.
It's called "installing apps".
the problem is transaction not done once you own the device, you must use the ecosystem
Google and Apple create this ecosystem and they own it, so even if you have 100% control of your device but you cant live without their ecosystem
OS is just "half the battle", if its so easy Microsoft would not let windows mobile died
but Open Ecosystem/Platform
which is likely never happen tbh, since the amount of resources that required is a lot and would need monetization which would end up like at position like this
You mean, GNU/Linux phones, Librem 5 and Pinephone?
not yet to diminish them who is build these Amazing tools/devices but I need to see it yet in real life
hell even if you want to buy them, they literally often stock out in certain areas
and we not counting technical expertise to operate the devices
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".
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.
> Unironically, I want finished software.
But I'd definitely love to not be shipped alpha or beta software. MVPs are great when hacking, but why are we shipping hacked together stuff. "It works" doesn't mean it actually works...
Back when it came on physical media, it was very much finished. Needing an update to fix a critical bug or a UX issue was a very costly problem to have, both in money and in reputation. Users had to be convinced to buy and install major updates, instead of being strong-armed into it. Staying on an older version was easier, and in case of operating systems, much more widely accepted.
Many video games fall into that category even today. Sure, the "we can always release an update" mentality did infest game developers as well, but, unlike apps and OSes, most games do have a finite scope and stop being developed once that scope has been realized.
> Back when it came on physical media, it was very much finished.
It's a great situation when a bug is discovered and it is hard to patch.
You're fantasizing about a time that never existed. Software isn't "ever finished" because we are not omniscient writers who can foresee all problems, fix all bugs, and write software that is unhackable. That's the mindset that "all tests pass" or "it works for me" means the software "works."
We can't address the problems, as discussed in the article and that I mentioned in my comment, if we're going to retcon history and redirect ourselves to a worse environment. That doesn't fix anything.
We'll never be omniscient, sorry. The world changes. Hardware changes. Software rots. Time marches on. These do not change and we have to operate in a world where we acknowledge these basic facts of reality. We'll never make decent software if we can't acknowledge reality first.
Did you live at a time where Internet was not a thing?
I remember very clearly buying software on physical media and never, ever "receiving" a single patch. I don't even know how that would have looked... "buy this floppy disk, it's a patch for a bug in the other floppy disk you bought recently"?
I remember being able to buy "the next version", though. But the expectation was that I was buying a "finished" version, not something unfinished that required me to buy all the next versions.
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.
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.
Except in cases like Debian (or Ubuntu LTS main collection, Redhat distribution...) which assumes the burden of backporting security fixes to a stable collection of software.
You should be able to set auto update, auto update with confirmation, manual update only, for any or all apps.
What someone does with that, and why, isnt something anyone should have to explain or excuse.
It could be as simple as not wanting any new features beyond but what an original version of an app has. Or not wanting an update that takes user data surveillance to another level.
Obviously saying "Apple shouldn't be allowed to touch my device after I purchase it" as well as "Apple should be compelled to provide security updates" is nuts.
But I think saying, "Apple shouldn't be allowed to touch my device after I purchase it" as well as "I should be able to provide my own security updates, if Apple doesn't want to" is totally reasonable.
But Apple would never allow that. So allowing sideloading seems like a reasonable amount of pain Apple should be forced to put up with...
Security Updates - They should be considered as in warranty servicing of faulty software.
Software Updates - These are turning out to be a scam in some ways. The decision to regularly introduce new APIs and forcefully obsolete old APIs/features is theirs. Consumers don't have to pay for it with the control. The cost of it should be baked into the initial purchase cost. A new feature that restricts access is an anti-feature.
Um, yes? Constant push-updates are one of the worst tech trends of the last 10-20 years.
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
But what's the point of defining these standards now? Is the world where this is the reality still feasible? It seems nearly impossible, unless you're an extremely wealthy and influential individual. What I'm seeing is that we never will move to a world where a device that you bought is truly "yours" anymore. Instead, we'll be renting one of the approved devices, ran by one of the tech megacorporations and overseen by your government. They will give no real way to execute any random code that you want, unless you're also licensed and vetted as a developer. They will be tightly surveilled, all information will be saved, every interaction between these devices will be controlled for the sake of security. It will be an entire web of trust, defined by the powers that be. We're seeing early attempts at it now, but we still haven't hit full centralization. But once we do, what happens then?
Fixing that problem might turn out to be cheaper for competitors by making their platforms more open and avoiding the full responsibility as a vendor.
Basically, combine current and future legislation about electronic waste, cybersecurity of IoT and connected devices, and the carve-outs for free software and open source platforms, and suddenly it becomes much cheaper to ship a product that will run for 20 years (say a washing machine) if you as a vendor can guarantee some of this for the warranty period (1-5 years), and open up the platform to consumers and shift the responsibility at that point. Also imagine the case of a vendor going under which needs to be covered too (this would make subscriptions infeasible too).
If legislation demands this (imagine no insecure devices for 20 years), markets will do the rest.
But isn't this also exactly how the pitch will sound for what I proposed? You know, "The internet is too important and random people are allowed to upload and run random dangerous code within it with no oversight, this has to be stopped." The manufacturers will never bear the consequences of their choices, the consumers will. There might be a push to make the internet watertight by requiring all major websites and services to only allow access to "secure" devices and block all other traffic. After all, why spend money on cybersecurity when everyone can only use the (important parts of the) internet with their real names, and developers are de-anonymized?
Will this actually improve security? It seems very unlikely. But despite it, this move seems like exactly the kind of thing that's coming, because it massively benefits both companies and governments.
At the moment, laws are disjoint even in EU, and not strict about what happens when you stop fixing security bugs.
So to answer your question: Ubuntu will let you access the next web, and Android probably won't.
If you're talking about developing some brand new means of worldwide communications, this seems extremely improbable if done by the 1% of the rest of us (basically, hobbyists and techy people). The internet required tens of billions of dollars worth of development and infrastructure to get to this point, how will it ever happen without the sponsorship of large centralized entities?
If you're talking about leeching off the existing internet infrastructure to communicate with some brand new protocols over them, who's going to let you do that? Both companies and governments would have incentive to put a stop to this in any way possible, because it drives away customers from the manufacturers and signers of all "secure" devices and lessens the amount/value of surveilled data. It may be allowed at a small scale, but I'm not seeing how anything long-term could be established that could threaten the existing powers in any way.
There was a time when "pamphlets" were an edgy new social medium, now its just a certain kind of ad. Same thing happened with radio. And now it has happened to the web also.
Why should this be the last time?
As for threatening the existing powers... I don't see what power they have if all they're guarding is a pile of stuff that nobody wants anymore.
It may be a bit inconvenient, but if you really need a device with radios that you can run arbitrary code on, you can get one for something like $4 and you can use your existing phone to drive it over something generic like http (There are plenty of people on meshtastic doing this).
I don't have the answers re: next steps but I know that its far more difficult to prevent people from communicating in novel ways than it is to come up with novel ways to communicate. I figure we've been playing this cat and mouse game with authority for millennia: they always win eventually and we always find a new way to make that victory irrelevant.
We lost. OK. What's left to do but invent the next battleground? We're hackers, its what we do.
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.
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.
I am not saying it justifies locking down devices, but that's the kind of situation where I think a bit of friction is a good thing. For example having to connect your phone to a computer and run some command line tool (like for unlocking a bootloader). You still have your freedom, but it is also something you are less likely to do by accident. In the sideloading situation, it looks like you could make yourself a developer account and repack apps under your own identity, which is one of these high friction workarounds.
For F-Droid specifically, maybe they should negotiate with Google before going to the offensive. Maybe they did and it didn't work, but I think a good compromise would be to let F-Droid has a key to sign the apps they compile, making F-Droid accountable for the apps they distribute.
And by the way, Firefox is in a similar situation for extensions. Over the years, they made it really hard to install anything from outside the official Mozilla repository, citing security concerns. It is not just Google.
At some point you need to just let the user say "I'm OK with being accountable for the installation" and get out of the way.
Neither incentive alignment nor competency is sufficient without the other.
This is what has made Linux distributions the go to for secure OS to run on your server: even if malware or bug leaks in, you have a full security trail about when and how that happened right in the open.
By default, F-Droid provides only the applications that they themselves have verified and built from source. They also allow the user to add other sources from other parties who the user trusts (e.g. GuardianProject, IzzyOnDroid, and others[0]).
Google provides any application uploaded by any anonymous third-party who signs up as a developer (and in future, provides the required ID).
It’s not just a random hodgepodge of “third party” binaries. It’s all FOSS software that was actually built from source and verified.
Probably much safer than a random app on the Play 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.
It is an obvious solution, and it's a good first solution. This popup already exists.
A problem in security engineering is that when people are motivated (which is easy to achieve), they will just click through warnings. That is why, for example, browsers are increasingly aggressive about SSL warnings and why modifying some of the Mac security controls make you jump through so many hoops.
The usual take on HN is take the attitude that the developer is absolved of responsibility since they provided a warning to the user. That's not helpful. Users are inundated with stupid warnings and aren't really equipped to deal with a technical message that's in between them and their current desire. They want to click the monkey or install the browser toolbar. The attitude that it's not my problem because I provided a warning they didn't understand doesn't restore the money that was stolen from them by malware.
I think that's going to have a far more significant impact on people installing malware than developer attestation.
That said, your point about messaging is really good, and so many times I see security warnings I roll my eyes at how badly the message is written.
However, we need a better solution than pop-up warnings. I guarantee that you have clicked through a pop-up warning that was standing between you and the thing that you wanted to do (as have I, and everyone else who has used a computer for more than a day). We very quickly learn that most warnings aren't going to affect us, and that they're just saying "are you sure" to things that we're already sure of.
We've all selected a file, hit the delete key, got the pop-up saying "are you sure you want to delete wrong_file.txt", hit "yes" (because we always have to hit yes after hitting delete), then looked at the outcome and thought "oh, that was the wrong file" too late...
But some actions are pretty hard to undo (eg installing malware), so the issue in general stands.
Android already does this. It's the thing that's going away.
then you trust who??? Apple app stores?
I don't think it's like "MSFT didn't dare to try", but rather "MSFT was too stupid to come up with the idea". They didn't have the ability to manage it either (and till this day their Windows Store app still sucks with tons of bugs). Not to mention that Windows was already wide open, never with a restriction "you can only install these approved apps" to begin with.
Basically, not that Microsoft didn't do it, but it couldn't.
> 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.
Having a curated channel for app loading is indeed a valuable security tool. It does exist in Linux distributions as well. It does not mean that it has to be the only channel.
And it does make total sense, IMHO, to warn the users when they install something through an "unknown" channel. The first time you install an alternative store, it should tell you "you'd better be damn sure that this thing is not malicious because it will install all your apps".
Which brings me to a few points:
1. I don't really see a problem with the Google Play Store being installed by default on Google-certified phones, just like I don't have a problem with the GrapheneOS store being installed by default on GrapheneOS. But the Play Store should allow me to install alternative stores (like F-Droid), just like the GrapheneOS store allows me to install... the Play Store.
2. I should be able to install an alternative OS on my phone and relock the bootloader. Which actually the Google Pixels allow (one of the reasons why GrapheneOS runs on the Pixels). I don't see a problem in allowing Google-certified Android, it's just that Google should not be allowed (by law) to prevent me from running GrapheneOS.
3. Manufacturers should be forced by law to make it easier to some extent for alternative OSes, e.g. by opening the device tree and stuff. If they don't, they should prove that they have a good reason not to. Other than "hmm I don't know, but to be safe I will just keep it all proprietary".
This is true, but it's also not the main vector of attack. The primary threat is that the user is intending to download $WELL_KNOWN_APP and instead downloads a compromised binary from a malicious third party and is instantly compromised. The app stores make the probability of this essentially zero.
Oh no granny tapped a bad Google ad and got phished! I guess we should kill the open web and use the officially sanctioned “web store” from now on (where you have to apply, pay a fee, and of course a % commission to host a website). It’s much safer for us!
If this stops, it fundamentally disallows me to have the privacy that Apple app store can't provide. The amount of garbage apps in play store is horrible. I don't try out any new apps from there cos of this. So I will just switch to iPhone.
Already degoogled for pretty much most things. This will be the last. And maybe switch my website from netlify which I think is using google cloud (need to check).
Specifically it's weird to me that those people, akin your statement about platforms, don't seem to have a sense of place within which they do their stuff, whether that stuff is talking to the friends in your neighborhood regularly or checking your email; there aren't any other reasons you prefer Android, iOS is the default?
I personally don't fucking like iOS at all, never have, but I've always let myself re-evaluate it when the opportunity comes up. I find the UI clumsy and primitive, lacking in personality, customization, versatility. It was just fine on my old iPad for a few basic tasks, and it's still just as fin and just as basic, relatively speaking, on newer devices. However I am a career-long macOS user by choice. I usually admire both macs and iPhones for their hardware design.
Likewise, even though I moved to my relatively high cost of living city for a job years ago, if my current one let me WFH exclusively, I'd move... nowhere, this is exactly where I want to be. There is always some threshold of course whereby favoring one choice over another is too costly to maintain, but even though this particular freedom topic is important to me, I'm not about to just switch platforms because I've secretly hated it otherwise.
Because that is important to them. Everybody has different opinions on different things. Their priorities are different. I prioritise privacy. I had a workflow with convenience and privacy setup I can do with Android now. It had a lot of loopholes but it is something I am satisfied with. Its something I have developed it by making compromises and adjustments based on privacy, convenience and functionality. So FOR ME, it becomes valueless after this change. And the better would become iOS. So I would change.
I could also argue that yours is a boiling frog situation where you are fine with bad changes around you but you keep getting adjusted to it and making excuses.
For example, due to my privacy setup, I rarely see ads, I rarely get scam calls. There are convenience I get because of it.
All you have to think is... If whatever these companies do online... Will you be OK with it if they do it offline and in person?
Imagine I follow you everywhere and keep telling me to buy a burger from McDonalds. Stalk you around, noting everything you do. And about your family. How long will it take for you to call the cops on me or confront me? Why are you complacent when these companies do the same online? End result is literally the same. Only difference is scale and the fact that one is happening in your face while other is out of your view.
In conclusion, Everybody's threshold (like you mentioned) to different changes are different based on their views and priorities.
And most importantly, as a software professional, we definitely should hold ourselves to higher standards. I am doing what I CAN now.
GrapheneOS has official production support for the following devices:
Pixel 9a (tegu)
Pixel 9 Pro Fold (comet)
Pixel 9 Pro XL (komodo)
Pixel 9 Pro (caiman)
Pixel 9 (tokay)
Pixel 8a (akita)
Pixel 8 Pro (husky)
Pixel 8 (shiba)
Pixel Fold (felix)
Pixel Tablet (tangorpro)
Pixel 7a (lynx)
Pixel 7 Pro (cheetah)
Pixel 7 (panther)
Pixel 6a (bluejay)
Pixel 6 Pro (raven)
Pixel 6 (oriole)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.
Imagine if your car was locked to certain manufacturer-permitted destinations.
That's what our smartphones have done.
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 :-).
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.
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.
Things were bad.
Any evidence this was caused by "sideloading"?
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
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.
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
Perhaps you meant Leviathan instead of superego?
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.
But yeah agree, this subscription thing is spreading like a cancer.
EDIT: and, shucks, @kragen beat me to it! :-)
[1] https://en.wikipedia.org/wiki/Phoebus_cartel#cite_ref-USvGE-...
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.
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 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.
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.
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.
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.
Could literally replace the control software with a potentiometer (a resistor)! :)
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.
The plea Google makes against so-called "sideloading" always refers to "malware"
But how much malware has been distributed via F-Droid versus "Google Play Store"
It could be that smaller, independent "app store" might be better managed than Google's
That is essentially the assertion that we made in the prequel to this post (at https://f-droid.org/en/2025/09/29/google-developer-registrat...).
> 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".
Because Google is suggesting that "malware" is a motivation/reason/justification for their new "sideloading" policy
It can be useful to show that Google's alleged justification is bogus
It's not about immediate safety, it's about safety in the long run.
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.
> 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.
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'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.
I too am flabbergasted at the utter lack of integrity some show and vocally proclaim in this of all places… corporate shills every last of them.
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.
.. A grateful F-Droid supporter and user.
> 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.
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.
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.
It was ported[0] by enthusiasts to literary almost every Android phone. I have it on my $100 Xiaomi.
> 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.
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
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.
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 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 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.
Have a nice day.
Because the Play Store is a proprietary ecosystem that's being often used as a political tool.
If Google starts to ban alternative stores then Android will fragment and much of the world will move to Chinese alternative OS's.
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.
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?
They want to punish customers for electing regulators who care about consumer protections.
This is large scale abusive boyfriend behavior, doubling down.
Anyone who defends google/Android has been heeled in fear.
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.
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"
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.
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.
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.
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.
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.
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.
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.
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.
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.
[1] https://www.xda-developers.com/how-to-sideload-apps-android-...
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.
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.
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?
>Lando: But that wasn't our deal!
>Vader: I have modified our deal. Pray I do not modify it further.
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.
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.
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".
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
https://www.apple.com/tr/privacy/docs/Building_a_Trusted_Eco...
> Lots of people SAY "sideload"
It's almost like you didn't read the post
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.
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.
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?
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.
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 am not sure if you are disagreeing with me or ignoring my point :)
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.
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.
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.
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?
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.
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.
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.
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"?
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).
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.
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.
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.
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.
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 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.
sudo apt install vrmsNo surprises on my system except for the firmware-intel-* packages. I thought those were free software? Must be binary blobs.
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.
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 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?
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.
>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.
If you find yourself making a statement only to immediately contradict it, consider whether or not that statement is worth making at all.
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.
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.
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.
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.
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 ?
We would miss out a lot of creative people making software.
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.
Obviously they'll eventually remove this because Google is hostile to things like ReVanced / some spook wants this power.
* Search for "Smartphone-1 to Smartphone-2" "adb tcpip 5555" in "Motorola moto g play 2024 smartphone, Termux, termux-usb, usbredirect, QEMU running under Termux, and Alpine Linux: Disks with Globally Unique Identifier (GUID) Partition Table (GPT) partitioning": https://old.reddit.com/r/MotoG/comments/1j2g5gz/motorola_mot... (old.reddit.com/r/MotoG/comments/1j2g5gz/motorola_moto_g_play_2024_smartphone_termux/)
* Search for "termux-adb" in "Motorola moto g play 2024 Smartphone, Android 14 Operating System, Termux, And cryptsetup: Linux Unified Key Setup (LUKS) Encryption/Decryption And The ext4 Filesystem Without Using root Access, Without Using proot-distro, And Without Using QEMU": https://old.reddit.com/r/MotoG/comments/1jkl0f8/motorola_mot... (old.reddit.com/r/MotoG/comments/1jkl0f8/motorola_moto_g_play_2024_smartphone_android_14/)
I'm definitely not 100% sure about that though, so someone please correct me if not.
- 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¹
- 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...
EDIT: Even more googling, the whole setup already exists in Obtainium (i.e. F-Droid but with Github Releases) apparently so apps show up as being installed via Play Store and subsequently be usable in Android Auto⁵.
So hypothetically you can install stuff day one on a stock phone after this atrocity is turned on.
[2]: https://shizuku.rikka.app/
[3]: https://f-droid.org/en/packages/com.aefyr.sai.fdroid/
[4]: https://f-droid.org/en/packages/io.github.samolego.canta/
thank you for the testing and details!