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.
