This is something that no Linux phone enthusiast seems to understand.
Also if we use atomic distros with flatpaks and whatnot that mimic Android security the end user basically ends up having to essentially use Termux (but busybox or something similar) on their Linux phone as well
Atomic distributions don't provide the security of verified boot or the far better mandatory app sandbox and permission model on Android. Flatpak is catching up to Android from 15 years ago, but it isn't mandatory. Android continues making backwards incompatible privacy and security improvements via new target SDK versions on a yearly basis with apps forced to adopt it within around a year. It continues moving towards a more private and secure model for apps.
GrapheneOS makes our own major improvements to the permission model, but we cannot enforce apps adopting it and need to design it all to be backwards compatible. We do that for Contact Scopes, Storage Scopes, our Sensors toggle and other features but not everything can be done that way. For our exploit protections, we have toggles to work around apps with memory corruption bugs or bad practices such as dynamic code loading. Android can enforce apps improving in a way we can't do. We're starting from a platform with a mandatory app sandbox and relatively modern exploit protections though. Android also does support using hardware memory tagging or HWASan to test apps even though many developers aren't using those to clean up their memory corruption bugs.
On my Linux laptop, I use bubblewrap sandboxes with their own encrypted filesystems and granular permissions for each of my projects. Very easy and secure with NixOS, surely better than what I could do with an Android device.
No, it doesn't come anywhere close to the privacy or security provided by AOSP.
You could be dividing up your projects into highly sandboxed environments on Android too. It has support for running multiple hardware accelerated virtual machines running desktop Linux and it wouldn't be that hard to support creating those with NixOS and other distributions instead of only the standard the Debian images provided by Android. That will happen as it gets more mature.
See the explanation at https://news.ycombinator.com/item?id=49364220 for why desktop Linux is nowhere close to AOSP for privacy and security. If you want more details, there's a lot of deeper coverage.
Yes, it does, at least for my threat model. AOSP (with Google Play Services, which are needed to do much useful) mean that a whole lot of closed source system binaries are running with full access to all my data and constantly phoning home to Google.
That is fine but obviously we are talking about threat model in comparison to each other.
>Google Play Services, which are needed
They are "needed" if you want to use other closed source apps that rely on play service feature. If you don't want/use closed source apps there is no reason to use Google play services at all, that's why they are optional.
>running with full access to all my data
GrapheneOS sandboxes play services specifically to run with user permission instead of system and can be used in a completely different isolated profile for your other private user data.
NixOS by itself does nothing to increase security outside of the supply chain. There is for example no default application sandboxing, Mandatory access control or hardened memory allocation (software or hardware). Just to name the most basic security feature.
AOSP security model relies on an extremely restrictive SELinux config out-of-the-box (that importantly also doesn't impede normal phone/app usage), with the kernel hardened about as much as any cutting edge Linux distro could offer from upstream, plus features that haven't been upstreamed yet (and again, completely transparently to the user).
Software for poorly isolating software on a desktop without a viable approach to containing arbitrary desktop software with a case-by-case consent model for access is not comparable to a mandatory app sandbox with yearly backwards incompatible privacy/security improvements. The whole app ecosystem has to support it and adapt to gradually improving privacy and security. Desktop applications are not written to work that way and do not have to adopt technologies people come up with catch up to Android versions from 15 years ago.
Traditional desktop Linux distributions have atrocious privacy and security. The security record is very poor. The security record does speak for itself in that it has been a disaster. iOS and AOSP have massively improved upon the legacy Unix security model. A traditional desktop OS cannot properly protect users from applications, remote attacks or physical attacks such as extracting data from an After First Unlock state device. It's not only the software that's very lacking but also the hardware and firmware for the Windows and desktop Linux ecosystem. macOS has a made a lot of progress for the hardware, firmware, hardware-based security within the OS and a gradual move towards a mandatory app sandbox and other protections which have not happened in the Windows or desktop Linux world.
AOSP has an increasingly usable desktop mode and supports running traditional desktop Linux within hardware accelerated virtual machines. It's not fully ready as a desktop replacement yet but it's getting there. Android will be shipped on many laptops in the future as a replacement for ChromeOS. The desktop mode is going to be the main way it functions on those so it's going to get much better. GrapheneOS has all of this functionality. Many people are trying out the latest Android 17 desktop mode on GrapheneOS and were already using the earlier experimental mode. Major improvements to that are coming. Many people are quite happy with this even if you don't want it.
> I think you are somewhat conflating the needs of desktop/laptop/mobile users.
No, we aren't. Desktops need far better privacy and security than they have today. That does not require giving up functionality. Development can be done in contained hardware accelerated virtual machines specific to projects. It doesn't require running an OS where anything goes and software doesn't run in a sandbox on the host. QubesOS could have a far more secure OS as the one people interact with despite running far less secure operating systems in many of the guests. It would not prevent people getting work done. It can also be done with far higher usability than is currently provided.
> Hardware security tied to unlocking modes makes little sense on desktops.
Verified boot and hardware support for disk encryption is very valuable to a desktop and laptop.
> I can lose my phone, or possibly my laptop, but my servers and workstation are at home, guarded by a dog and a shotgun.
Servers and workstations being in a trusted location doesn't mean the security of those against physical attacks doesn't matter. It also doesn't address remote attacks.
> Disk encryption already covers a realistic threat model such as a break-in.
You do not have comparable disk encryption. You have it in a form that only truly works when the device hasn't had the encryption passphrase entered since boot. It's wide open to data extraction via a bunch of debugging interfaces. There's incredibly poor security against physical attacks at both a hardware and OS level.
> I don't expect protection against apps, and don't want to pay the performance tax that comes with "enhanced" memory allocators and memory-safe languages/runtimes.
The performance cost of exploit protections can be determined in a granular way. GrapheneOS has a toggle to use the standard allocator for any apps. Memory safe languages do not imply inherent overhead and can be faster for some uses. Rust is very high performance and even Java can be higher performance for certain uses where there are lots of short lived allocations.
> The irony is that Android is practically designed to run commercial malware. The sandbox you have in mind does very little in practice.
Android's sandbox provides enormous benefits and the permission model gets significantly better ever year. Android has heavily focused on improving a lot of what you're talking about itself upstream and GrapheneOS improves it much more.
Android can force backwards incompatible changes on the whole app ecosystem to improve privacy and security which it does with each new major target SDK version for the major yearly releases. They limit how much they do this in each major release and aren't as focused on privacy and security as us so we wish they did more, but no other mainstream platform has made such substantial improvements to the privacy and security model for apps. Android has improved drastically more than iOS since it had a much worse starting point and had to catch up. It has caught up in most areas and surpassed iOS in some but still needs improvements in others. GrapheneOS is heavily focused on those areas where it's still behind iOS and has done a lot to improve it.
> Users consent to sharing files, contacts, locations, photos, when asked to because they want to use some app, and all of that is sent straight to Facebook, Google, or others.
GrapheneOS has Contact Scopes and Storage Scopes to choose which contacts and files/media are shared with the app seeing it as the permissions it requested being granted. This is an extension of Android's standard approach built on the infrastructure it provides for this. It's already heavily moving in this direction and has increasingly forced apps to use a case-by-case consent approach. Location, Microphone and Camera access in Android can be granted on a one-time basis. It heavily pushes apps to using the system file picker, media picker, contact picker, etc. and store policy is increasingly used as a deterrent against requesting bulk access. GrapheneOS does much better and it's able to do much better because of the infrastructure Android provides.
> Android apps can also communicate in some obscure and unexpected ways to discover each other and share information behind the user's back
Communication better apps is possible within profiles where both apps want to engage in it. Users do have the ability to prevent apps seeing each other and communicating via profiles (Private Spaces, work profiles and secondary users). GrapheneOS will be providing finer-grained nested profiles beyond a single Private Space per user or a single work profile along with it being more convenient.
Apps getting access to user data in the first place is what's most relevant rather than whether they can communicate regardless. They could also send it to a service rather than another app. Android is focused on preventing apps getting access to sensitive data including data from other apps or the user's profile data (files, media, contacts, etc.) which GrapheneOS greatly enhances. We do have things like a Network toggle but it's not intended as a substitute for the main approach of avoiding apps getting access to sensitive data. Android is currently phasing in a standard local network access permission for apps will provide one of the main benefits of our Network toggle.
I think the disagreement mainly lies between whether one should be able to use their devices as they wish, like a desktop/laptop, or whether all devices should be restricted so as to have a good baseline level of security.
As far as I understand, the Linux phone enthusiast's POV is that we should start seeing the phone as another general purpose computer that can be set as per one's needs and can be suitably hardened as and when the need arises.
I wonder what environment the GrapheneOS devs use for development and other general computing needs, and if such an environment could be emulated on a phone (that is assuming, of course, that their development environment is way more hardened than current desktop Linux).
I suppose they could be using something like Qubes OS. I myself use a rooted phone, which does admittedly have security drawbacks but is useful in various ways.
GrapheneOS primarily exists to greatly improve privacy and security compared to the Android Open Source Project (AOSP). AOSP provides far better privacy and security than a traditional desktop Linux distribution. It has a strong mandatory app sandbox, an increasingly good permission model moving more and more towards case-by-case consent, broad use of memory safe languages throughout the OS and app ecosystem, strong MAC/MLS policies developed as part of the whole OS, modern exploit protections, verified boot with downgrade protection for the whole OS and far more. GrapheneOS starts from the already good privacy and security of AOSP and greatly improves upon it. We greatly improve the permission model, exploit protections and much more but we depend on starting from a foundation that's already decent.
Hardware-based security features including hardware memory tagging, a high quality secure element providing high quality interfaces for improving security, proper verified boot and more are definitely important too, but they cannot simply be bolted onto an OS. The OS needs to be built around being able to take advantage of these features.
Moving to a far less private and secure desktop software stack is going in the opposite direction from GrapheneOS. GrapheneOS doesn't exist to simply provide an alternative to mainstream operating systems but rather to offer much better privacy and security. We wouldn't be doing that if we were forking a desktop Linux environment and doing similar work for it. It would be nowhere close to the privacy and security of simply using an iPhone. That's a major part of why GrapheneOS is based on AOSP rather than it solely being about compatibility.
Desktop distributions are incredibly far behind on privacy/security and lack any clear path to achieving the same things. Every year, Android makes backwards incompatible privacy and security improvements as part of a new target SDK version. Android retains compatibility with legacy apps, but apps distributed through the Play Store (and other app stores to an extent) are required to move to the new target API level within around a year. This results in apps being forced to conform to a gradually improving privacy and security model. There's no such thing for desktop Linux apps but rather apps choose how much they want to participate in nascent sandboxing efforts.
GrapheneOS has near perfect compatibility apps from the Play Store via our sandboxed Google Play compatibility layer with the exception of banking and government apps. 90% of banking apps currently work on GrapheneOS because it greatly succeeds all of their security requirements and is only wrongly banned by a subset of those apps. These apps are gradually adding more anti-tampering and attestation checks for the hardware and OS, so maintaining compatibility has required us to gradually add more functionality working around it. We've also had to actively convince apps to stop banning non-Google-certified operating systems or to permit GrapheneOS and other secure options alongside doing it. A growing number of apps are choosing to stop banning using GrapheneOS due to pressure from our expanding userbase.
Android is a large Linux operating system family. It's the mainstream form of Linux on personal computers. Android users are Linux users. For privacy and security, using a monolithic kernel written in C is definitely not a good thing. Doing much better than we are today partly requires moving away from so heavily depending on the Linux kernel for security. Android does a lot of Linux kernel hardening with attack surface reduction and exploit protections which are improved by GrapheneOS, but it's not enough. The massive torrent of severe vulnerabilities being discovered in the Linux kernel is going to get worse before it gets better and will remain a problem. Adopting hardware-based virtualization for isolation of apps and OS components including drivers is an important part of our roadmap.
