Which is why alongside freedom came the business of anti-virus.
Many moons ago I attended an internal tech talk by the Google security team. This was shortly after they got hacked by China around 2010 or so. The talk was a general one on what they were doing to boost the security posture in general.
Number one thing they were doing was moving away from AV scanners on Windows to a regime in which IT would centrally whitelist all apps by signature or EXE/DLL hashes. Beyond the issue of false negatives, the reason was that people would routinely install malware infected software despite being told by the AV scanner that it was infected. They'd be told that and they'd just override it. Nearly always the reason was that they were installing pirated software and wanted it badly enough that they either didn't care that it was virus infected, or they talked themselves into believing a conspiracy theory in which AV companies reported false positives to try and discourage piracy.
The other problem with AV was that it reported true positives centrally, but then they'd be coming from high level executives and there'd be problems with addressing the issue. Whereas in a whitelisting scheme said executive would have to file a ticket to request permission to install the malware-ridden pirated Photoshop or whatever, and they wouldn't do it.
This was very sad and I don't know if they kept it up, that sort of thing is terribly high maintenance and it wouldn't be a surprise if they moved away from it at some point. But when your biggest problem is AV that is accurate but ignored and that's inside one of the world's most sophisticated tech companies, it's fair to say AV is not useless but if anything needs to be even stricter.
To be fair, pirated software often uses obfuscation techniques similar to malware, and then it's more like antivirus vendors refusing to add an exception for pirated software, rather than antivirus vendors specifically seeking out pirated software to mark as malware.
Also:
Certain types of scripts and software that I use to configure Windows in unsupported ways are detected as malware by major scanners. While I'm sure someone wouldn't appreciate these scripts being used on their computer by surprise, when I use them intentionally, I want their effects.
How is that curl https://... | sudo sh going?
Apple also has enforced a similar policy to what Google is doing, but much stricter, and has done for ~13 years or so (devs must be identified, the OS rejects unsigned code in all territories by default, Apple pre-approves all binaries even outside the app store).
Linux distros have policies far more extreme than anything Google, Apple or Microsoft have ever done. They explicitly don't support installing any software not provided by their "app stores". Getting into those requires giving up your source code to them, and they reserve the right to modify it as they see fit without informing anyone, reject it for any reason or no reason at all (including reasons like "we don't have time"), and they tie getting new releases of your app to the user upgrading to new releases of the OS. If you do try and install stuff from outside of your distribution, not only are there security warnings to click through but an expected outcome is that the OS breaks and the vendor washes their hands of you.
Despite those policies, or perhaps because of them, botnets of Linux servers are common.
Of all consumer-facing platforms only Windows and Android allow installation of unsigned third party code out of the box via some obvious graphical path. And on Windows that right is somewhat theoretical. You can do it but the built in browser will try very hard to stop you, and the OS itself will happily break unsigned code by blocking file open syscalls heuristically. So in practice most apps don't go the unsigned route. On Android OTOH, unsigned (non ID verified) code is sandboxed and works just like regular apps after installation, the OS won't heuristically interfere with the app.
Most Linux distributions don't prevent you from installing third party software at all. You download something, you set the execute bit, it runs.
Users are wary of doing that with software from untrusted sources because, obviously, you're then placing your trust in whoever provided the software instead of the distribution's packaging team. But the OS won't stop you if that's what you want to do, and sometimes you do trust the source of the software.
> Despite those policies, or perhaps because of them, botnets of Linux servers are common.
Botnets of Linux servers are common because some people operate them without security installing updates (common with WordPress), and then attackers exploit known vulnerabilities in the unpatched software.
But "locked" phone platforms regularly discontinue security updates for devices that are still in widespread use. Locking the device doesn't solve that problem at all, and in fact makes it worse because then if the OEM doesn't patch it nobody else can do it either.
The OS doesn't stop you installing third party software - signed or not - on macOS, Windows or Android, so "allow" is nothing interesting. That also won't be changing with Android, given that you can buy a phone with an unlockable bootloader and reflash to some other spin of Android that implements whatever security policies you want. You can put these devices into a mode that allows anything.
The question is whether that's something the vendors make easy, if they support it in the sense that you can do it and they will still deal with you if there's a problem. That's what support means. It's not a synonym for technically possible.
Windows, macOS and Android don't consider installing third party software to put the system in an unsupported state. Linux vendors do.
The concern is that they are now doing this on Android, and have long been on iOS. Moreover, there are really three things here: Fully supported, still easy enough to be practical, and so much friction that it's dead.
If you install Steam on Windows, Microsoft doesn't "support" that -- if you call Microsoft support and want them to fix a problem with Steam, they're going to direct you to Valve. But installing Steam on Windows is easy to do, and therefore common. And it's the same thing with installing Steam on Linux.
Likewise, you can get Linux software from the distribution's repositories, but you can also use pip or npm or flatpak or any number of alternative packaging systems, and doing this is easy and common.
Which, on Android and iOS, it isn't. It's not just "not supported" but so arduous that the alternatives can't gain traction, which is qualitatively different and has consequences in terms of network effect even if it's technically possible to install LineageOS on a handset if you buy just the right one and immediately reinstall the OS and keep a separate phone to run your bank app. And even then you still can't install a mainline kernel on that device and are reliant on the OEM to keep publishing security updates.
Even with this new policy there are still ways to install unsigned apps on Android e.g. via adb, reflashing to a different build of Android, and so on. But you're absolutely right that there's a spectrum of usability here, which is why "allow" isn't really a useful standard. Only iOS tries to set friction to 100%. Every other platform "allows" third party installation given enough work, which is why it's valid to compare the difficulty of doing so on Linux with other platforms.
Re: Steam. Microsoft absolutely does support that! If you install Steam, Windows breaks, and Steam isn't doing something disallowed like messing with internal data structures, then Microsoft will accept it as a bug in Windows. They work very hard to support apps even when they actually do mess with internals. It's the Linux world that shrugs if a change in Linux breaks Steam when Steam was doing nothing wrong.
Flatpak is a genuine improvement, yes. But for the rest, sorry, you have developer brain switched on! Pip! Easier to use than Android!? These tools:
• Only target developers, and as such regularly do things like try to compile software during install and then fail due to obscure compatibility or versioning issues.
• Have severe malware problems.
You couldn't present pip or npm to the Android team as a solution to the problem they're trying to solve. You blame Android for being "arduous" whilst desktop Linux has spent decades with <5% market share exactly because it's so incredibly arduous. Come on: even with these new policies it is much easier for both users and developers to access/make software on Android. I've developed and distributed software for every OS except iOS at this point, and the differences are clear.
Sure, but the point being, it's a lot easier to install software from outside of the repositories on Linux than it is on Android. Measure by how often it happens. Do a significant percentage of desktop Linux users ever use something other than the official repositories? Yes. Do a significant percentage of Android users? Nope.
> Re: Steam. Microsoft absolutely does support that! If you install Steam, Windows breaks, and Steam isn't doing something disallowed like messing with internal data structures, then Microsoft will accept it as a bug in Windows. They work very hard to support apps even when they actually do mess with internals. It's the Linux world that shrugs if a change in Linux breaks Steam when Steam was doing nothing wrong.
I don't think this is accurate. If there is actually a bug in Linux, they'll accept the bug report regardless of whether you discovered it while using Steam or something else.
> Only target developers, and as such regularly do things like try to compile software during install and then fail due to obscure compatibility or versioning issues.
Nah. If you want to use some random AI thing or web thing that isn't in the main repositories, it's going to be telling you to install dependencies using those tools regardless of whether you're doing any software development.
> Have severe malware problems.
This is true but not unique. If you use a package distribution system and it has malware in it, it has malware in it. It doesn't matter if it's Google Play or pip or something else. It doesn't matter if it's operated by the same entity who made the device. What matters is if the people operating it do a poor job of excluding malware, and then some are better than others. Google Play has more malware than F-Droid or the Debian repositories; npm has more than Google Play.
> You couldn't present pip or npm to the Android team as a solution to the problem they're trying to solve.
The interface for some of those things are tuned for developers, sure. If you make an interface for ordinary people then it looks more like F-Droid than npm. But then that's what you'd do -- except that the F-Droid installer isn't allowed in Google Play, which leaves ordinary people in the chicken and egg where you have to do something technical to get access to the interface that makes it easy for ordinary people.
> You blame Android for being "arduous" whilst desktop Linux has spent decades with <5% market share exactly because it's so incredibly arduous.
Desktop Linux has been growing at a pretty significant rate. It's now above 5%, and it wasn't so long ago that it was under 2%.
The main problem isn't the difficulty of installing third party software but rather the network effect of getting people to make it to begin with. If hardly anybody uses it then developers don't make software for it and then people who e.g. want to play games get a Windows PC etc. Which makes it slower to gain market share. But despite that, the number keeps going up rather than down.
> even with these new policies it is much easier for both users and developers to access/make software on Android.
The thing you really need is the ability for someone who has never done it before to make Hello World and get it running on their own phone, and that is not easier on Android than on a Linux desktop.
I recently upgraded macOS, and it took me a couple of reboots and scarily-worded system configuration changes to re-enable (signed) kernel extensions…
Linux distributions each have their built in package managers, but there's no 'policy', as I understand it, that prevents installation of, literally, whatever you want. It's generally more difficult than just downloading and double clicking on the installer / exe, but just follow the instructions and it's done.
And, yes, also there are weird version and dependency issues that crop up more than would be ideal, but that's not the topic.
And, note, back when I was a Linux user, distro vendors and evangelists justified that situation by security. They said we don't want people distributing software outside of our repositories because that's how Windows users get viruses, so we deliberately won't make it any easier.
So the Linux community doesn't get to cry freedom and decentralization now, IMHO. The time to do that was 25 years ago when Debian was being praised for having big repositories. Some of us actually did point out how centralized and authoritarian that approach was, I even built a system for distributing apps in binary form to all distros (with hacks and shims for binary compatibility), and that projects attracted some volunteers, but we got pilloried for not "getting" UNIX. One Debian developer even called us monkeys.
The users got tired of this and bypassed them with Docker, a much more decentralized system in which anyone can publish images without binary compatibility problems, and using them isn't tied to your OS version or OS vendor policies. But Docker is also centralized around Docker Hub, and Docker Inc do ban images and developers when malware is found:
https://jfrog.com/blog/attacks-on-docker-with-millions-of-ma...
Not so different to what the app stores do.
It's fair to say that the only OS vendors who have ever taken decentralized and free app distribution seriously are Apple, MS and Google. The open source world went all-in on the centralized store model from the start and never looked back.
Sure, the Linux ecosystem has not prioritized binary compatibility as much, so doing so has been harder, people culturally expected "use existing libraries" more than "just bundle everything", but as you note that attitude has shifted too and it always was possible, and nothing seriously suggested preventing it.
Never heard that argument, ever. `apt-get` literally allows you to add whatever repositories you want. You're conflating two completely separate worlds. The first is the world of Linux that pretty much invented the idea of a software repository for an operating system. This was invented because Linux has the notion of "distros", and the trick there is to provide a set of packages that all work together in that distro. That's the purpose of curating packages in the repos (along with Free Software licensing, in the case of distros like Debian). But this system was always federated, where users were empowered to add any additional software repositories they needed. F-Droid on Android copies the exact same architecture, allowing the user to add endpoints of servers they want to pull software from.
The second is a system of control built by Google and Apple. It has nothing in common with the Linux system, but rather was designed to vend proprietary software that extracted money from users, for the purpose of lining Google and Apple's pockets. When Tim Cook testified about app store fees and the judge queried him about why they were so high, he said "To lower those fees would be to give up the full return on our App Store investment." Basically: we're charging this much because we can.
Conflating these two systems and the reasons for their design would be very misleading.
> It's fair to say that the only OS vendors who have ever taken decentralized and free app distribution seriously are Apple, MS and Google. The open source world went all-in on the centralized store model from the start and never looked back.
It is not even remotely fair to say this. In fact, it's so misleading it feels malicious. The only operating system on the planet that offers user-supplied software repositories that work with the built-in package management system is Linux. Full stop. And Linux doesn't even only have one of these systems, it has several. Flatpak, Debian repos, Ubuntu repos, Arch's AUR, Slackware's third party repos, etc. And users don't have to "work around" the system to use any of this - simply adding new URLs works great, and it's always been this way.
https://wiki.archlinux.org/title/Unofficial_user_repositorie...
https://documentation.ubuntu.com/server/explanation/software...
In short, Windows and MacOS and Android have never taken third party software distribution seriously in the least, and have done nothing to support it. Linux has built-in support for third-party repositories, and has for decades.
They all have sophisticated systems in place specifically to support third party software distribution that works (and is relatively safe):
• Windows has the app store, MSI, and MSIX (which allows efficient installs and updates from arbitrary web servers). MSIX is a package manager, by the way. It also has API support for writing AV scanners, managing software deployments across managed networks and so on.
• macOS has .dmgs, notarization, Gatekeeper
• Android has support for installing APKs from the web with a package identity system that lets anyone self-sign their software.
Above all they consider installing apps that aren't controlled by the vendors to be a core feature, so they work hard to provide binary compatibility, bug workarounds, multi-year deprecation cycles, anti-malware scanners and more, all for the benefit of developers who develop their apps independently of the vendors.
Linux can be reconfigured with additional repositories, technically, but that feature was originally designed for reducing bandwidth usage with mirrors. It wasn't meant to allow third parties to distribute software on their own schedule, which is why these third party repositories are invariably locked to a specific version of a specific distribution. Developers who complain about this are just told every version of every Linux distribution is a unique OS, and that they should open source their apps to let distributors centrally take ownership of their work.
It's changing a bit now with Flatpak. But for the bulk of Linux's history, that was the gig: no supported way to distribute your apps, and third party repositories would come with health warnings from your OS vendor. Not a supported way to use the OS. If it breaks you keep the pieces.
The stuff about Linux not letting you install stuff flies far in the face of like everyone’s knowledge of Linux. Your description of how Linux installation works is pure fantasy.
I've been a Linux user for 25 years. You can reconfigure the OS to use additional repositories. It may or may not work, and only if there is a repository specific to both your distro and its version. But it's not a good idea.
In particular, OS upgrades are very likely to break. Being able to upgrade itself is a basic requirement of any modern OS. If your Linux distro corrupts itself on upgrade or fails to do so and you file a bug report you'll be told to remove any third party software because that's not supported.
This would be like if your Mac started crashing on boot because you downloaded a word processor from a website, and then Apple say "sorry, we only support apps coming from the app store". They don't do that, but Red Hat or Canonical will.
I've used Ubuntu, Debian, Manjaro, Mint, and Fedora, and none of them are like this. Which distro do you use that doesn't let you install any software you want?
Nonsense. You can and run install whatever you want. Tons of closed source commercial software available for Linux like Matlab come as a .tar file which you extract and run.
But we certainly support your _ability_ to install and run whatever you want. It's your computer, and it's your OS.
And although I was making that argument to Fedora decades ago, it's only recently that this point has been accepted with official support by Red Hat for stuff like Flatpak. Of course other distros developed their own thing as always so it's still not really ideal. But at least the principle was now accepted that third party apps should have a properly supported way to thrive. Far too late, but it's done.
Working in retail tech support, we got folks bringing in their new macbooks, freshly ruined by new ransomware, utterly baffled that it was possible at all. But when you're trying to use Photoshop without paying... well, shady stuff's still out there.