Strong disagree. Linux, its permission system and its (barely existent) application isolation are lightyears away from the security guarantees that Android brings.
Desktop OSes and their derivatives are woefully behind in this regard, and unfortunately the will to bring them up to par is incredibly weak. Of those in mass use (Qubes OS is neat but its user base isn’t even a rounding error), macOS probably does the most, but it’s still lagging behind iOS and what’s been implemented has come with much consternation from the technically inclined peanut gallery.
I understand some amount of reticence with commercial OSes, but there’s no justification for being against it on open Linux based desktops and mobile OSes. We really need to get past the 90s-minded paradigm of everything having access to everything else all the time with the only (scantly) meaningful safeguards coming in the form of *nix user permissions.
> We really need to get past the 90s-minded paradigm of everything having access to everything else all the time
I do agree with that, and I strongly believe that the iOS and Android security model is way ahead of Desktop Linux. But what I observe is that nobody seems to care about the security model. A recurrent complaint I see against anything AOSP-based (including Android) is that people "want to be root".
It comes from a history of using mostly trusted application sources like Debian/Ubuntu package archives with manual review being the norm. And few supply chain attacks.
But both Flatpak and Snap offer this new model from the two biggest desktop players in the Linux world: Red Hat and Canonical.
As the sibling comment said though, being an administrator for your own computer (including a phone) does not mean that you will be running untrusted applications as one: on the contrary, if you assume an administrator role and run an untrusted application, naturally, all bets are off. But even as a power user, I'd love to be able to safely run programs I do not necessarily trust, feeding it only data it needs and no more.
Again, Snap/Flatpak provide this model, but we need to see more application authors take them up to ship their software.
It comes from a history of using mostly trusted application sources like Debian/Ubuntu package archives with manual review being the norm. And few supply chain attacks.
What most of these people do not seem to get is that proper sandboxing does not only protect against attacks from the inside (rogue developer, supply chain attack), but also from the outside. Most desktop apps probably have a good number of security vulnerabilities that can be exploited when they parse untrusted data. On the Linux desktop, most apps still use decades-old C libraries for parsing XML, images, JSON, etc.
Sandboxing also protects against external attacks.
Again, Snap/Flatpak provide this model, but we need to see more application authors take them up to ship their software.
Agreed, though for a lot of technical and social reasons, most apps still need privileges that allow trivial sandbox escapes on Flatpak (I don't know or care about Snap). Strengthening app sandboxing should be a top-priority for the Linux desktop, but only a few people seem to care. The same for fully verified boot, etc. Even things like UKIs only go so far, yet almost no distribution has adopted them.
The general security mindset of the Linux desktop community seems to be stuck in the 90ies, levitating between hahah, they cannot get root (as if that matters on desktop Linux) and secure boot and sandboxing is here to take my rights (on open source desktop Linux, seriously?).
I think you are mistaken. Just like neither Windows nor MacOS have really solved the desktop app sandboxing story, so neither has Linux.
Because, as I said in a sibling comment and cosmic_cheese notes further below, this requires rethinking the usage model altogether: files and folders, and even file types, don't work anymore.
If an app needs to access any related files, it basically needs access to my entire $HOME, and once that is granted, well, any sandboxing is out the window.
I think Linux community is well aware of that, and basically what we get from sandboxing of desktop apps is all the nuisance with no benefit.
Android model is also broken from a usage perspective: having files "owned" by an app is just as wrong, and precludes there being multiple apps operating on the same file. Example of VLC with subtitles is a common one, but if you've never used multiple apps on the same file, this is the challenge that is unsolved by any sandboxing approach today, because it is more of a UX problem, than a sandboxing technical problem.
> What most of these people do not seem to get is that proper sandboxing does not only protect against attacks from the inside (rogue developer, supply chain attack), but also from the outside.
The problem is that strict file system sandboxing in particular also breaks a substantial number of workflows that can't be modelled as 'only ever open the exact file the user explicitly' picked. (Any multi-file file formats are particularly affected, as well as any UI workflows that don't integrate well with strictly having to use the OS file picker.)
So you need some escape hatch for optionally allowing access to larger swathes of the file system, or even really everything as before, but that in turn then risks being abused again by malicious actors. And then…?
Plus things like Android's implementation initially using an API completely incompatible with classical file APIs, as well as causing some noticeable performance overhead even today if you need more than simply accessing the occasional single file here and there.
Agreed. I want to "own my device" as in "being able to install the system I want on it". Not as in "I want it to behave exactly like Desktop Linux", or whatever it is that people complain about AOSP.
On my Desktop I love Linux. But on my smartphone, I want AOSP.
Allowing the owner of the device root access doesn't necessarily break the security model. It just means that the user can grant additional privileges to specific apps the owner has decided to trust. Every other app still has to abide by the restrictions.
The fact that Android complains and tells any app that asks whether the owner actually, you know, owns the device they paid for is an implementation detail.
A Linux distribution that adopts an Android style security model could easily still provide the owner root access while locking down less trusted apps in such a way that the apps can't know or care whether the device is rooted.
IMHO, I should be able install the OS I want on the hardware I paid for. What should be illegal is to technically prevent me from installing a different OS, because I paid for that hardware and I should own it.
But that does not mean that all OSes should be open source. I think it's fine for iOS to be proprietary, but there should be enough information for someone to write an entire alternative OS that runs on iPhone. I think it should be illegal to prevent that (is it called tivoisation?).
All that to say, I don't believe that having root on my Android system is a right. But being able to install a system that gives me root should be one. If that system exists, that is.
> A recurrent complaint I see against anything AOSP-based (including Android) is that people "want to be root".
I want to be able to do what I want with my PC or phone. I don't want every app on my PC or phone to be able to do whatever they want, without me agreeing first.
I want to be able to install what I want on the hardware I own. And I should be able to leverage the hardware to its full capacity. Preventing me from adding custom keys and relocking the bootloader should be forbidden, because I own that hardware.
But that does not mean that I should be able to do whatever I want with any OS I install. If I am not happy with Android, I can install LineageOS and modify it the way I want.
I am obviously not a big fan of Google, but I do believe that AOSP is actually a good deal (a lot better than iOS which is proprietary). Google is doing a lot of work on AOSP. That I cannot unlock/relock the bootloader on some devices is not Google's fault.
It's important to keep separate the parts of the security model mobile did well from the parts it got wrong. Declaring that app developers can decline end user access to app files is unacceptable. I get final say on my device. I get to run as root. Hell, I get to run as ring 0 if that's what I want to do.
IMO, the developers choose what software they want to write. If Microsoft Word decided to remove the "export to PDF" feature, that would be their right. And it would be your right to stop using Microsoft Word. If you want to be root on your system, you are free to install a system that gives you root access.
And that's the part that I believe should be a right: if you buy a smartphone, you own that piece of hardware, and you should be able to install the system you want. But if you are not the one developing that system, you don't get to decide what this system does. Just like you don't get to decide whether Microsoft Word can export to PDF or not.
You're saying that the Android security model shouldn't be illegal. I agree.
I'm saying that despite all they get right, the Android and Apple security models, when foisted on the mass market, are socially and ethically flawed. I'm saying that the end user has a fundamental right to tamper with the software on his own system. Those designing an OS that intentionally thwarts the user's will are in the wrong.
Just because something is legal that doesn't mean doing it is a good thing.
Do you have any source for that claim? That would be a pretty serious security issue even unrelated to any security hardening (eg. on a multi-user system, one user could read out the password from another user — even with desktop usage, second user could be SSHed in).
As a datapoint, everything in /dev/input/* is owned by root:input on my Debian Bookworm install, and my main user is not a member of the "input" group either.
Biggest problem with most security hardening for Linux desktop is that it breaks the natural usage pattern: I store my files by their content, not by their format (eg. I might have a folder for my project containing image files, spreadsheets, FreeCAD files, maybe even some code or TeX/ODF files). If programs are restricted to access the entirety of my $HOME though, there is not much benefit to that protection since that's where my most valuable data is. If they are restricted to per-program folder, I need to start organizing my data differently and unnaturally.
Android mostly does not use the "files" metaphor and basically does exactly that (per-app data): coming up with a security model and file management UX that does both is where the challenge is.
It's the same reason I choose to keep my front door unlocked basically all the time - I know my neighborhood, the risk is really low and the convenience is high.
Further... practically everyone agrees that they don't need bank vaults as front doors. It makes zero practical sense: The cost is incredibly high, and the convenience is very low.
There are ALL sorts of wonderfully cool things you can do on a system where applications are allowed to trust each other, and the system is permissive by default.
You can customize behavior more easily, you can extend software more easily, you can add incredibly detailed & functional accessibility support, you can create incredibly powerful macros and commands.
This is so important that fundamental OS design from the early 90s actually prioritized and catered to exactly this style of open, trusted, platform (ex - all of COM in windows...). This is what made personal computing a reality...
All of those fall flat when you try to impose "well funded" security efforts.
Those efforts have a place, in the same way that bank vaults have a place. Whether that place is a personal computer is a different question.
Implying those folks are hostile for no reason is... at best a woeful misunderstanding of the situation, and at worst a malicious mischaracterization.
Flatpak and Snaps are built to solve this. They do conflict with some expectations from users to be able to play around with things, though, so they do not have the penetration one might want.
They only cover the user-facing app part of the story. The rest of the system needs isolation and safeguards, too, including things like the desktop environment and whatever random daemon.
A solution that's integral to the system and not just loosely taped on is required.
Docker style containerization technically works, but for desktop use I think is a rather heavy kludge and not really a solution.
It would be much more nice if e.g. daemons could have their privileges pared down to only exactly what they need to function and nothing more with a config file somewhere. This can somewhat be achieved with the user system, but that really doesn’t scale well and doesn’t suit the purpose all that well in some ways.
Letting everything I install have access to everything is the core feature I want out of a platform. If I can't have that might as well just use android
This might be a strange take in these times, but I feel like the browser largely solved the "I need to run potentially adversarial application code in a sandbox". For native applications, stick to stuff that's vetted and in well-maintained repositories, or well-known open source projects that you trust. All of this technical work just to be able to run hostile native code ignores that you don't have to, and probably shouldn't want to, run sketchy code on your device. Installing random untrusted software is bad, even with the most advanced security model in the world. At the very least it will probably abuse whatever permissions it has to spy on you to any degree it can (which is a lot, even for web pages) and to send you advertising notifications.
This assumes that the mentioned systems are the only security considerations on a Linux system. Clearly this is not the case so I am unsure why you omit other security-related aspects of Linux here.
Android, being based upon the Linux kernel, has all those and its own app permission system built on top. Linux on its own comes nowhere close to this.
The security of Android doesn't mean much to me as long as the front door is left open by design for Google, and therefore the government, to directly spy on you.
I.. don't think it will happen. For several reasons too. It is not that I don't think Android will change substantially, but the following constraints suggest a different trajectory:
- AI boom or bust will affect hardware availability
- there is a push on its way to revamp phones into 'what comes next' -- see various versions of the same product that listens to you ( earing, ring, necklace )
- small LLMs allow for minimal hardware requirements for some tasks
- anti-institutional sentiment seems to be driving some of the adoption
I understand why mobile/tablet OSs are so crappy compared to desktop; in the past these devices had no resources cpu and ram wise and had to heavily watch battery consumption (the latter is still true mostly, but that should be up to the user), but my phone is more powerful than my laptop and yet runs crap with no real usable filesystem and all kinds of other weirdness that's no longer needed.
However, I have 2 Linux phones and Linux on phones is just not there. Massive vendors (Samsung, Huawei, etc) would need to get behind it to make it go anywhere. Also so banking etc apps remain available also on those phones. We can already run android apps on Linux, Windows apps, so it would be a bright future but really it needs injections and support for large phone makers.
I hope the EU/US mess will give it somewhat of a push but I doubt it.
FWIW, Nokia did develop a pretty good Linux phone back in the day (Maemo/Meego) with Nokia N9 (it even received rave reviews from consumer tech sites like engadget), but it did get killed off as they got absorbed into Microsoft (we all know that didn't age well).
Similarly, Palm Pre, and especially HP Pre 3 was a wonderful WebOS incarnation.
Ubuntu Touch did seem like it had a future, but it was a massive sink for Canonical so it was defunded as well.
The user experience was there on all of these: the apps, not so much.
Ubuntu Touch is not dead though, I use it happily on my primary device for 8 years. It's working like a charm. And waydroid allows you to run APKs, even if some bank apps may not work.
This is one of the most naive things I see people repeat.
The reality is that we're lucky to have mostly-good things at all that align with most of our interests.
Yet people get so comfortable that they start to think mostly-good things are some sort of guarantee or natural order of the world.
Such that if only they could just kill off the thing that's mostly-good, they'll finally get something that's even better (or rather, more aligned with their interests rather than anyone else's).
In reality, mostly-good things that align with most of our interests is mostly a fluke of history, not something that was guaranteed to unfold.
Other common examples: capitalism, the internet, html/css, their favorite part of society (but they have ideas of how it could be a little better), some open-source project they actually use daily, etc.
If only there weren't Android, surely your set of ideals would win and nobody else's.
Agreed that there is a ton of baby in this bathwater.
Also, the open nature of AOSP gave Google its advantage during the early days. Since then, Google has morphed into a company that would likely not make the same decision to create an open-source OS free for others to use and contribute to.
So in the end, what we as consumers actually get, in 2026:
- Google encourages application developers to use hardware attestation to prevent themselves from running on non-blessed, third-party AOSP distributions.
- Google builds basic functionality people care about (including passkeys!) into Play Services, a closed mega-application that happens to require a Google account for most features, and is a moving target for open distributions to mimic.
- Google has closed AOSP contributions to themselves and OEM partners only. AOSP releases are now quarterly source dumps.
- OEMs which traditionally allowed bootloader unlocking (and thus actual ownership of the hardware) have removed it as a matter of policy.
So what exactly is open about Android anymore? Does "source-available OS you can see and not touch" align with your interests? Because it's increasingly not aligned with mine.