I've never really understood why we chase Android-alikes on mobile platforms instead of trying to build on mainstream Linux. I know some folks in the nix community (nix-on-droid and other projects) have tried to bring us closer to this, but projects like Graphene seem to have a lot of traction.
All the existing apps are on Android and iOS. Graphene lets you run them. You can't have a bank account on a Linux phone* because they won't let you, but you can on Android including on Graphene.<p>* before replying snarkily that Android is Linux, please take a long walk off a short pier, thanks
> All the existing apps are on Android and iOS. Graphene lets you run them.<p>We have waydroid for that.<p>> You can't have a bank account on a Linux phone* because they won't let you, but you can on Android including on Graphene.<p>Unless of course it uses those stupid integrity apis to block anything that isn't stock.
Graphene passes basic integrity, so most of them work. There is a list here:<p><a href="https://privsec.dev/posts/android/banking-applications-compatibility-with-grapheneos/" rel="nofollow">https://privsec.dev/posts/android/banking-applications-compa...</a>
Porting traditional Linux desktop distributions to Android devices is meaningless, all you get is more instability, more unsafe and more trouble. Waydroid is a bad implementation on security and compatibility, just running Android in VM is better.
> Waydroid is a bad implementation on security and compatibility, just running Android in VM is better.<p>What security problems does waydroid have that a VM wouldn't?
Waydroid disables most of the Android privacy and security model through not having functional SELinux. SELinux is not simply an additional layer of security on Android but rather deeply integrated into the OS. The app sandbox and isolation throughout the OS are heavily built on SELinux. It also heavily depends on it for kernel attack surface reduction combined with internal kernel hardening via exploit protections.<p>Waydroid uses an outdated fork of LineageOS running with namespaces and a compatibility layer on top of a much less private and secure base OS without similar kernel or userspace security protections. Running up-to-date AOSP in a virtual machine would at least be able to preserve the internal Android privacy and security model for apps to protect apps from each other and the OS from apps. It would also contain the overall OS within it too. Using the much less private and secure OS as the host OS with full access is quite backwards from a privacy and security perspective but would be a huge improvement.<p>AOSP is much more private and secure than traditional desktop Linux distributions. Moving to that software stack is inherently going to be moving much further away from competing with the privacy and security of iOS. The direction taken by GrapheneOS is to start from AOSP and greatly improve the privacy and security it provides to compete with and exceed the industry standard privacy and security provided by iPhones. That requires more than only software. Hardware and firmware security are very important too. Software security also increasingly depends on hardware-based security features such as hardware memory tagging, hardware control flow integrity protections, hardware-based virtualization and much more.<p>Keeping user data safe from access via encryption also depends on hardware security features for the vast majority of users not using a very strong passphrase. People take it for granted that they're going to have secure data via disk encryption with a random 6 digit PIN but that's not the case without a good secure element and OS integration with it. The approach used by desktop operating systems with TPMs is awful and makes security worse in a lot of ways rather than better. It's not at all the same thing, similarly to how what the desktop world calls secure boot is not a serious or complete implementation of it and doesn't provide nearly any useful security properties to end users unlike iOS or AOSP.
There are other reasons for porting, like control over your own device.
Traditional Linux desktops support traditional browsers as do all banks, etc.
The bug is letting the asshats make their own apps and force them on you through a store ecosystem which is basically a DRM deployment tool.
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.<p>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.<p>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.<p>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.<p>Waydroid uses namespaces and a compatibility layer to run an outdated fork of LineageOS. It's far from providing full functionality and compatibility with apps and nowhere close to the compatibility provided by GrapheneOS. More importantly from our perspective, Waydroid disables most of Android's standard privacy and security model through not supporting SELinux and other core parts of the security model. Android doesn't simply use SELinux as an additional layer of security with targeted policies but rather it's deeply integrated into the OS. It uses very strong whole system policies to implement the app sandbox, drastically reduced kernel attack surface and a lot more. Namespaces for the overall userspace environment are not a replacement for the app sandbox, kernel protections, verified boot and the rest of the security model.
The claim I responded to was:<p>1. Android has existing apps.<p>2. A subset of existing apps will refuse to run on various shades of non-stock/unofficial system.<p>I pointed out that 1. the existing apps largely <i>do</i> run on other Linux systems via waydroid, and that 2. apps refusing to run on non-stock systems are likely to refuse GOS as well.<p>If I cut down your page of text to the relevant points, I believe it amounts to:<p>1. GOS has better app compatibility than waydroid.<p>2. GOS is supported by some apps that would refuse other non-stock systems.<p>3. GOS is more secure/private. (This is unrelated and should at most have been a reply to the root comment.)<p>On 1. compatibility, yes you're probably ahead, though I have to question how much since waydroid is <i>also</i> 90% AOSP. Somewhat similarly on 2. yes GOS has gotten some buy-in, but if 90% is good enough, then again you shouldn't be holding up compatibility as your advantage over waydroid. Basically, either users want 100% app compat - in which case GOS is out - or they don't, in which case waydroid is likely to be an option. Point 3. is irrelevant to the conversation, and you probably don't want to start an argument about general features since GOS is missing vitally important features compared to other Android ROMs let alone "normal" Linux systems (how long has GOS been without full backup functionality now?).<p>> 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.<p>What other secure options are those?
What's stopping me from using a browser to log in to my bank? Assuming my bank is one of the ones that requires you to lock down sideloading (they aren't, but i know many are).
I had to replace a credit card yesterday. Part of the default flow involves the call center sending a notification to your app.
When I told them my android version was too old, it took them twenty minutes to find out they could instead send a text message. That text message sends you to a photo-and-id verification service, but that's another issue.<p>Soon, there won't even be an alternative flow. There are a lot of places where there already isn't.
Are you sure? This seems like a forum with a lot of early adopters and a lot of late adopters still use browsers, email, text messages. Like, let me guess that your credit cars isn't capitol one. Not that it should be, but that would be more "normie".
Banks are quick to adopt anti-money-spending measures because it allows them to hold your money longer and because money that can't be spent can't be fraudulently spent which they'd have to reimburse you for.
In Europe at least, most banks require IOS or Android. Even to login into the web Frontend.
Nothing is stopping you. You're free to use a desktop web app that either doesn't work or is terribly slow or has limited features on a mobile web browser. I'd love it if all apps were PWAs but that is not the case.
My broker has a much more fully featured web app then it does on iOS or Android. You can do things in a browser that the phone apps will send you to a browser to do. BofA is just as good of a web app. Maybe people are just used to using their phones?
Looking down the thread I am also thinking maybe this is a Europe thing? I am usa.
Can you deposit checks from the webapp? That is the feature most often missing in banking webapps. It isn't something I need often, fortunately.
The majority of the world don’t do this anymore.
Asking for a cheque deposit is like asking for a car with a hand crank. People outside USA are going to look at you like on a member of a Sentinel tribe.
That's not terribly compelling. Android and iOS banking apps also don't work, are terribly slow, and have limited features.
Eh? The bank apps I’ve seen appear to be webviews wrapping their mobile site. Much to my chagrin, I’ll add.
The websites don't have feature parity with the apps these days. Things like being able to deposit a cheque aren't available among other things.
Some older banks do have more features in their website than their app. It's usually the ones with the worse, most outdated UIs and almost useless mobile apps. After years of using several mobile-first neo-banks, I switched to a traditional bank and boy, was I not ready for the trip back in time.
>deposit a cheque<p>That would be inconvenient if this was 1985.
Some banks are app only and/or build MFA functionality into their apps.
> What's stopping me from using a browser to log in to my bank?<p>The "security module" they require you to install on your computer. In the past, when browsers had plugins, this was a browser plugin; nowadays, it's an always-on service (running as root) which exposes a local HTTP server which the bank site connects to to validate your computer. For an example from a major bank in this country (the same "security module" is used by several banks in this country), <a href="https://seg.bb.com.br/home.html" rel="nofollow">https://seg.bb.com.br/home.html</a> is the diagnostic page for that "security module" (the FAQ page there has links to the installers).
The bank website typically needs the app to enable two factor authentication in a lot of places.<p>For eg. There's no browser based alternative to make UPI payments that i know of.
In many countries, all major local banks require their phone app as the second factor to log in to the browser version of their online banking. Sometimes functionality is removed from the browser version and made available only in the phone app.
"Many" is doing a lot of work here. A more accurate statement would be that some banks in some countries require invasive apps, but fortunately it isn't the case everywhere (yet).
This is a huge problem in EU countries!<p>The relevant regulations are Commission Delegated Regulation (EU) 2018/389 and the earlier Directive (EU) 2015/2366.<p>While these laws are deliberately vague when it comes to specific technologies, they do require at least two independent factors from different categories, such as knowledge (password) and possession (phone).<p>That, in and of itself, wouldn't be a problem. The way most banks implement it, however, is by giving you two choices:<p>1. You use their mobile app (which likely requires device attestation and Google Play Services, so won't work on a plain LineageOS install)<p>2. You use their CardTAN device, which is extremely inconvenient to always carry around.<p>Sure, we nerds might argue they should just let us use our Yubikeys or regular old TOTP, but pretty much no bank implements that. (Why? Your guess is as good as mine.)<p>Personally, I had to buy a second stock Samsung phone just for banking apps. And yes, there are still alternatives (only very very few though), but no, none of them are convenient, for various unrelated reasons.<p>I wouldn't be surprised if this continues to spread to the US too, under the sneaky disguise of "security".
I see people from US being surprised when they see success stories by people from EU stating "maybe it's a US thing" and people from EU being surprised when they see success stories by people from US stating "maybe it's a EU thing".<p>In reality, most of time it's just a matter of choosing the right bank wherever you are. I'm writing this on a GNU/Linux phone that does my banking just fine. I'm from the EU.
And what do people without a smartphone use?
Name five.
The 2FA code you need to get from the phone app to log in on a desktop. It isn't 2005 any more.
Apparently I live in 2005 then? I do 2FA with the same chip+pin method that I use to pay in the store. Works in any browser
Highly location dependent. This is more true in Europe than in America.
my bank (and others) doesn't require the 2f to be a smartphone
Right, 2FA. My bank wants me to log in to my phone app and then sends an SMS to the same phone to confirm the app transaction. It's super-secure.
Well, it's kinda hard to scan a QR code displayed on your screen when the camera is attached to its back (semi-joking)
The bank itself. They want to see where are you, what you do and snoop on anything they can about you. Having a spywa^W sorry, bank app is the best way to do that.<p>Source: my bank which recently 'upgraded' a browser version to a glorified SPA which even renders as a vertical oriented app on a landscape 4K monitor.
I use my web browser to access my bank and tell banks that require apps to go fuck themselves.
Even Graphine is limited in what apps work properly compared to a normal google phone. You have to give up a lot in order to have privacy these days.<p>A pure linux non-android phone would be great however you wouldn't have access to properly working apps and would not be able to participate in modern society.
Not true, if you install play services you can run 99.9% of apps, i can even run all the italian apps from yhe goverment.
You are still using google but its running as user service and you can even revoke most of the permissions including location.
Using BMW digital keys seem to be a problem because of the lack of google wallet support (supposed to also be an issue on Lineage).<p>Anyone getting BMW digital keys to work on Graphine OS?
Running their sandboxed Play, I can run everything. The only thing I notice in the US is some banking apps (stupidly, idiotically, moronically) force 2FA on every login instead of trusting biometric entirely like they do on stock OS.
I can't care less about "apps". Web is already powerful enough to do all sort of stuff on device.<p>That said, I think wasi containers support for a mobile OS would be a game changer.<p>(^ Here's a startup idea if you're looking out for one. I for one throw out all my devices from the balcony to get this)
yea i straight up am not downloading apps anymore if i can help it. virtually zero companies put apps out to provide a better experience, they just do it to get telemetry data. which is why all these banking apps are just their website in some wrapper lol
You can run wasm components in tauri apps, and tauri supports building for android.<p>I haven't figured out how to make them talk with each other though. I imagine that's the place where I'd notice this lack of support.
> Graphene lets you run them.<p>It seems not all of them, and that things will only get worse if recent news comes true.
> You can't have a bank account on a Linux phone<p>Somehow I do.
yeah, people suggesting Android is Linux are as annoying as people saying Digital Unix/Tru64 was OSF/1, or MacOS/OSX is now Darwin or OSF/1 or Gnu Hurd itself.
Banks care very little about actual security. Some force you either to SMS codes, or to their app on a hopelessly broken platform based on shoving many untrusted spying apps onto one device and hoping some SW will be able to keep them apart.<p>Almost none support strong dedicated HW authenticators or second factors. Not even as an option to those who care.<p>Anyway it's always possible to just reverse their web api and use it directly. 2FA that consists of copying some code from SMS is no barrier, especially not on the Linux phone that you fully control.
But they care a ton about security theater. Advanced device integrity? That sounds secure to me!<p>I should make a chip called Super Security Sauce Silicon, and make cards with them, and market them to phone vendors so their customers won't need the card, and market them to banks so their customers will be secure. It performs Dual_EC_DRBG with my keys.
A lot of it is security theater plus lazy (as in "doing the minimum amount of work possible") compliance with regulations
Some (European) banks/healthcare apps block GOS and require stock android. Just saying
I wonder if practices will change any of there's ever a device that ships with GOS. Right now, many companies are happy to shrug off GOS, because they don't support "modified devices".<p>If any of the Motorola devices have GOS as a pre-installed option, now the companies don't have the excuse that the device is modified.<p>I'm guessing the companies will continue to be difficult, but it'll be amusing to watch, at least.
What is the point of apps for these things in particular? I understand that some banks require an app for 2FA, but I don't see why anyone would want some invasive healthcare app on their phone.
Yep. Had to change banks because of my old one suddenly dropping grapheme support by adding stupid attestation mechanics.<p>They surely must have gotten feedback from me and others because the next update it worked again. But I and probably others where already a lost customer.
most banking apps don't run on graphene
Everyone else mentioned the app support which is true, but for graphene specifically, they do not like desktop Linux at all because they don't like its security. They would much rather build on AOSP than desktop linux.
True, security seems to be the main reason. But while desktop linux is community driven, AOSP is controlled by Google. So long-term, GrapheneOS is at the mercy of Google, no matter what. And also in terms of security, Google is becoming more hostile, where since a while, the GrapheneOS team is not allowed to publish all security patches source code in a timely manner: <a href="https://discuss.grapheneos.org/d/26476-backports-quarterly-releases-security-patches-embargoes" rel="nofollow">https://discuss.grapheneos.org/d/26476-backports-quarterly-r...</a>
Beyond the other answers here, doesn’t it make sense there were some reasonably bright people involved in the initial “let’s build a phone OS” and that given it’s sold more than a billion devices, maybe what Linux on a mobile device looks a heck of a lot like Android?
Because you need app support. Not even Microsoft could pull that off.
You mean Microsoft proactively kept shooting devs in the kneecaps?<p>Leaving phones behind on old incompatible OS versions 2 times in 3 years and switching app frameworks 3 times in 4 years does not a good app developer experience make.<p>Piled on top of that, Google became actively hostile to 3rd party developers building support for YouTube (and Gmail and Gmaps, but those had workarounds / alternatives).
What a colossal disaster. I was a huge Windows Phone fan, so their yearly missteps were quite painful to watch. I was especially annoyed when my first gen WP wasn't going to get an upgrade to WP8. My HTC 7 Pro is still my favourite phone I've ever owned, but after that I finally gave up and switched to Android.
What about running the whole Android infrastructure, but on top of a non-Android Linux distro? And this, on top of a Android kernel (otherwise you won't have the drivers yo uneed)<p>The advantage being, we can manage packages using a regular Linux distro
A lot of "non Android Linux distributions" like sailfish os actually use a lot of Android infrastructure to keep working.<p>Drivers doesn't just mean the kernel. It's the user space binary blobs and services that need to talk to the kernel to enable the hardware.<p>Other than that there's waydroid, alien dalvik etc.. that run another Android instance in a container.<p>The thing is a lot of Android applications use safety net/other methods to make sure they only run on. "Approved"/stock hardware.
Android has a proprietary HAL on both ends; the userspace interfaces to drivers are not the same as on "normal" Linux for almost any devices (baseband, video acceleration although this is at least EGL based, cameras, sensors, audio DSP, hardware media codecs, etc.), so by the time you replace every component of the OS, you've just made AOSP without the useful security parts.<p>> The advantage being, we can manage packages using a regular Linux distro<p>It's much easier, more plausible, and more logical to sandbox a regular Linux package-managed distro inside of Android, which numerous solutions exist for.
This is exactly where my head goes. There's nothing special about this hardware other than its small form factor. Sure, some desktop apps would likely want a different skin, but thats hardly limiting.
You can't because a lot of apps check that the phone is controlled by Google with Play Integrity.<p>Google thought about this, don't worry. They learned their lesson after CyanogenMod tried to compete by offering an alternative. Non-Google Android are now dead except in China.
CyanogenMod became LineageOS and its still going strong, im typing this on an unofficial lineageOS build right now.
Well for me I use Lineage without even MicroG and everything I need works - yes even banking
App support, stable ABI, uniform UI/UX, hardware vendor cooperation...
I dont think app support is all that important. Most apps are garbage as they are ime, so rebuilding from scratch, or using existing software that runs fine on linux, would keep me happy.
Microsoft could, but abandoned just as they gained traction in Europe
Doesn't windows run android apps natively now?
Microsoft can barely pull off their flagship desktop operating system, so that doesn't say much.
GOS is broadly compatible with most phone use cases out of the box--chat, mail, browsing. A Google Play profile lets me use almost all apps (including my bank apps, but I understand that's not true for everyone).<p>In principle I agree about a Linux phone, but the gaps are much greater. I am also sympathetic to the GOS team's arguments that sandboxing on Android is better, and important on a device that allows control of essentially my whole life (2FA apps etc.)
Because Android is miles ahead in terms of security, permission management, app separation, power management, privacy...<p>Linux crowd can not even agree on compositor, and if systemd or sudo is a good idea.
I strongly disagree. The only reason I still use an Android phone is that countless third-party services (that are too useful for me to give up) require the Android/iOS ecosystem.
> Linux crowd can not even agree on compositor, and if systemd or sudo is a good idea.<p>This is actually a feature.
Why should Linux users have to agree? run what you want, it's your computer.
once Huawei was forbidden from using Android - that's when people ie western markets & the world at large should've shifted. look at HarmonyOS.<p>in China - there's no google apps available on their 'android' versions.<p>their platforms are already performant and fluid - so people should build on that.
Like others have said, it comes down to apps mostly. But there is also the fact that Google and others have spent more than a decade optimizing the OS for appliances. Android was built from the ground up for mobile devices and handles things like background apps, notifications, and charging as expected on a phone. All of this could be ported or rebuilt, but the work has already been done for Android and billions of devices prove that it works.
Apps. We'd love a completely different OS and it is viable on desktop because web almost does everything but on mobile you're basically locked out of very essential functionality like banking, transit, messaging etc. The compatibility layers aren't good enough (yet) to offer a seamless experience.
Seems like it's the same problem as chromium. Is it <i>better</i> to get off the Google controlled ecosystem? Yes. Is it easier to leverage the Google controlled ecosystem? Also yes.<p>People will tell you that chromium is "more up to date" as if Google wasn't the one setting the standards, making it impossible for anyone else to be similarly complete. Seems like we have a very similar problem here...
AOSP has way better security and therefore privacy than desktop linux.
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.
This is something that no Linux phone enthusiast seems to understand.<p>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
Stop repeating this nonsense, AOSP isn't any more "private" than Linux. AOSP is only more "secure" because, on some devices like Pixels, it exploits hardware features typically not found on general purpose computers. By default, Android also limits user control and takes root away. That may be a sensible design for an appliance, but it isn't something we should want on desktops.
> AOSP is only more "secure" because, on some devices like Pixels, it exploits hardware features typically not found on general purpose computers.<p>You don't think, say, isolating apps has anything to do with it?
i recently put debian (mobian) on a pixel 3a and it's pretty solid, though i haven't tried it out as daily driver yet.<p>claude code makes stuff like that super accessible to do in your spare time. another example is installing debian on a synology 918+, there's no way i would've had the grit to do that without ai. it's open season for any gadget that's got a debug uart port.
I have a Pinephone Pro. It's nowhere near usable as a daily driver.
Because without Android I can't run WhatsApp and my bank's app on my phone, which promptly reduces it to a paperweight. I wish it wasn't so, but reality refuses to cooperate, so let's just be happy that we've got GrapheneOS which is so good it has its own column in Cellebrite's support matrix.
> without Android I can't run WhatsApp and my bank's app on my phone<p>Yes, you can, although it may require tinkering and compromises: <a href="https://itsfoss.com/whatsapp-linux-desktop/" rel="nofollow">https://itsfoss.com/whatsapp-linux-desktop/</a> and <a href="https://news.ycombinator.com/item?id=49363246">https://news.ycombinator.com/item?id=49363246</a>
Yes, there's SailfishOS, there's Ubuntu Touch, and a couple more. It would be nice if one of them could gain traction so people can have a third choice.
Because it's a mobile platform and "GNU+Linux" is laughably terrible in this space.<p>It's almost like Android has put millions of expert dev hours into making it the most used OS in the world. Like GNU+linux on laptops only works the way it does because of android-upstreamed battery saver kernel features.<p>But a mobile is also people's most used devices with all of their data, bank accounts etc there - it has to be safe. And GNU+linux has not even a single thought about security, while android just has it worked out (every app runs as its own user, so it's even built on standard UNIX security).<p>A mobile OS also has to race to suspend and for that it needs cooperation from "apps" -- desktop apps just run, they don't care about anything besides SIGKILL. That's not a workable model on a mobile and android solves it.<p>And I say all that as someone who runs linux everywhere I can and I absolutely love it. It's imo the best kernel out there -- but the userspace is not where it should be and if anything, the correct question would be what can we take from Android and add to GNU+Linux. (And nix is fantastic, but it's a packaging solution, I don't really see how it comes into question here. I can run nix on my android phone just fine by the way)
Nix comes in because im tired of dealing with procedural solutions to things that should be solved declaratively. I run NixOS everywhere I can because I can actually reason about what is installed on the system. "Package management" like apt and pacman and even app stores has never done it for me.<p>As to your other userspace concerns... these are all solveable. Perhaps with some elbow grease, but devices like the Steam Deck prove that mobile linux isnt as much of a problem re: userspace as you claim.<p>Ed.: I'd also like to add that the fuss around security is _mostly_ Google propaganda. Android is not meaningfully more secure, _without application level changes_ than Linux.
<p><pre><code> > but devices like the Steam Deck prove that mobile linux isnt as much of a problem re: userspace as you claim.
</code></pre>
So.... by relying on yet another company with multiples of $10B in revenue who spent a lot of time and money to build (and maintain) an entire custom frontend/compatibility layer to provide a stable UX for managing apps without intimidating non-tech savvy users? Where security isn't even a distant priority as it's a restricted store in a proprietary walled garden exclusively for games (and not your banking app or crypto wallet or browser tabs)?<p>SteamOS, very similarly to Android, entirely depends on a corporate benefactor leveraging a parallel user space that happily bypasses the "normal" community-supported parts of a typical Linux desktop distro wherever they present an obstacle. It proves that a company with deep pockets could indeed create a new mobile Linux distro (by writing lots of checks and cutting out large chunks of desktop Linux in favor of custom implementations entirely under their control).
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.<p>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.<p>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.<p>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.<p>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.
I have read your marketing materials. This question was aimed at a more-neutral audience. I really dont appreciate calling Android the "mainstream form of Linux for personal computers"; this is misleading in about four different ways. Android is not a Linux distro nor is it directly derived from Linux. Mobile phones are not "personal computers". Trying to act like it being "mainstream" or "common" relative to desktop distros matters is just laughable.<p>Ed.: And I take issue with the notion that a monolithic kernel cannot be secure. If your primary selling point is "well, we just do everything better!" then why arent you guys working on the next kernel for personal and high-performance computing?
> I have read your marketing materials<p>GrapheneOS is a non-profit open source project. We provide documentation and other information on the project.<p>> Android is not a Linux distro nor is it directly derived from Linux<p>Android is a family of Linux distributions. Linux is a kernel without a specific userspace and there are many different choices of libc, shell, init system, command-line utilities and far more. There are even more choices for the high level user interface. Android's userspace is largely specifically written to run on top of the Linux kernel with extensive use of SELinux and other Linux-specific APIs. A lot of the software you're considering to be Linux also runs on FreeBSD and elsewhere. FreeBSD is not Linux and the traditional desktop software stack largely shared with FreeBSD isn't Linux either.<p>Android Open Source Project uses the upstream Linux LTS branches. The upcoming devices with GrapheneOS support from Motorola use latest Linux 6.18 LTS branch. We plan to port to newer Linux kernel branches throughout the lifetime of the devices. Google already does that for Pixels and it needs to start happening for other devices too.<p>The upstream Linux LTS branches largely exist for Android with Google contributing a lot of the resources for it. Ubuntu and RHEL make their own LTS branches rather than using the ones from the Linux project. The lifetime for the upstream branches was increased from 2 to 6 years alongside Pixels increasing the support time to 5 years with the Pixel 6. It was decreased from 6 to 2 years because Pixels have been smoothly moving to newer kernel branches in production. It demonstrated the lack of need for the longer LTS branches not only for Android but more broadly. Pixels moved to 7 years of support with the Pixel 8 which wouldn't have been possible sticking to 1 kernel branch without a further lifetime increase.<p>> Mobile phones are not "personal computers".<p>Mobile phones are absolutely personal computers and should be treated as such. Many people use a mobile phone as their main personal computer. In large parts of the world, mobile phones are people's only personal computer.<p>GrapheneOS can even be hooked up to a monitor, mouse, keyboard, game controller and other accessories. It has a very functional desktop mode. It can also run desktop Linux applications via the hardware accelerated virtualization support. It even has opt-in GPU acceleration via gfxstream. That's all standard functionality from the Android Open Source Project.<p>> Trying to act like it being "mainstream" or "common" relative to desktop distros matters is just laughable.<p>There are billions of Android users. Each of those users is a Linux user. Linux is the dominant OS family on personal computers due to Android.<p>> And I take issue with the notion that a monolithic kernel cannot be secure.<p>A monolithic kernel written in C with an extreme focus on performance at the cost of having immense complexity is not reasonably secure. Piling on better exploit protections is useful but has a limited impact and those protections don't work as well in the Linux kernel as they do in the much more security-oriented userspace. Everything in the kernel being in the same address space with no isolation for regular code is not a good setup for security and severely hinders the usefulness of many exploit protections.<p>Further reducing attack surface even more than Android does is possible but is difficult while maintaining app compatibility. Hardware-based virtualization is the most realistic approach to dealing with the insecurity of the Linux kernel to properly protect it from userspace.<p>Protecting drivers from exploitation largely involves moving most of the code to userspace which is the norm in the mobile world and should expand much further. Bluetooth, Wi-Fi and other code can be largely moved out of the kernel. Moving TCP/IP, filesystems and many other drivers out of the kernel is entirely possible. However, it starts to run up against the Linux kernel having a culture and approach strongly against doing it. The same thing has happened with the attempt to introduce Rust in the Linux kernel with immense resistance and obstruction to simply providing bindings to write non-core drivers in it. There's no current attempt to use Rust in the core kernel and it would be an immensely slow process even if that was happening.<p>Hundreds of severe vulnerabilities being found per month with only a subset of those getting fixed is not a sustainable approach to making a reasonably secure OS.<p>> then why arent you guys working on the next kernel for personal and high-performance computing<p>We're doing initial work on expanding use of hardware-based virtualization to further reduce reliance on the Linux kernel for security. We're also building up our resources to be able to take on much bigger projects. Aside from that, we don't need to be doing things entirely on our own.<p>A lot of what we want aligns with where AOSP is already headed and many others want the same things. AOSP added hardware-based virtualization with the userspace code written in Rust and a more secure approach to handling it in the kernel (pKVM) without our involvement. AOSP also began to make very limited use of this for OS sandboxing itself. We want to do much more with it and use it for sandboxing apps, which are not things Android is currently working on as far as we know but likely will be in the future.
One word: ecosystem. Phones are useless bricks without an ecosystem. This is why we only have 2 operating systems for portable devices when we used to have more than twice the amount.
I don't either. Don't we have free market capitalism? Why don't I have a Linux phone? And why do I need to worry that my government and banking apps won't work if I get a Linux phone?
Because in a free market you can't compel someone to support your niche platform, nor even compel someone to create the niche platform you want. The market for a Linux phone is tiny because there's almost no reason for the average phone user to prefer it over android.
I cant tell how tongue in cheek youre trying to be, but capital rules all. I don't have billions of dollars like the trillion dollar companies do, so I am not "free" to "compete" with them in any meaningful way. Same goes for these businesses convincing governments and banks that they have to do it their way or the highway.
Because you don't have capital.
well, apparently not even Microsoft had enough capital.<p>It's almost like the free market only works when we have <i>well-defined and regulated markets</i>. This has been known by Adam Smith and quite logical, yet people expect Google and Apple giga-corporations with monopolies to somehow abide by the laws of selling grains on the market.
"Trust me guys, the free market will work, it's just that no-one ever earnestly tried it before!!"<p>No. This is the end state of any semblance of laissez-faire economics. Full stop. Massive accumulation at the top, power to those with capital, rags for the poorest.
no, we don't, far from it.<p>(which doesn't mean there's not a lot farther from here).
> Don't we have free market capitalism?<p>Not in the mobile world no, it's not a free market by any means
Because the Android Runtime (ART) is very necessary to run APKs, and APKs are the only non-iOS standard for packaging mobile apps that is supported enough to be viable. Without it, you might get some open source apps to run on a linux phone, but you won't have banking apps, clash of clans, or a million other things people really would like to have on their phones.
Your point is valid for every flavor of Android <i>except</i> GrapheneOS.<p>GrapheneOS’ security model makes that of desktop Linux look like a joke.<p>This is an objective analysis based on x86 security, GrapheneOS hardening (including isolation and hardened mem allocator), Pixel hardware security.
Even AOSP has selinux enabled by default with very comprehensive and scoped policies. That, along with app isolation and permission system, already leaves desktop Linux far, far in the dust on security.
All we had to do was build PWAs instead of native apps and instead all we did was build PWAs into bad browser wrappers.
I don’t see PWAs becoming dominant so long as web development stubbornly retains its highly atomized “bring your own everything” philosophy. At the very minimum, there needs to exists a community-accepted web UI framework with a similar level of “batteries included”-ness in terms of scope and depth as that of SwiftUI/Compose, or preferably that of UIKit.<p>The existence of such a framework would make the various tradeoffs with going web-only sting less and make that the advantageous route, not just the cost-cutting route that it’s seen as now (and why those bad browser wrappers continue to proliferate).
> I've never really understood why we chase Android-alikes on mobile platforms instead of trying to build on mainstream Linux.<p>Because there is no such thing as "mainstream Linux" when it comes to anything related to user-facing consumer software. Not on desktops, not on tablets, not on phones.<p>I mean you invoked "mainstream Linux" and "Nix" in the same paragraph. That alone should clue you into why this, absolutely, does not work.<p>See here is the problem:<p><a href="https://wiki.pine64.org/wiki/PinePhone_Software_Releases" rel="nofollow">https://wiki.pine64.org/wiki/PinePhone_Software_Releases</a><p>"Linux enthusiests" would rather muck around with rewriting the same software over and over and over again because they dislike using GTK or whatever, and put monumental amount of efforts making new package managers, then, say, getting the ability to take simple photographs using a phone camera.<p>I mean... In that page there is no less then 25 different "Linux Phone OSes" listed.<p>None of them actually work.<p>They are all going to be slow, they are all going to burn through battery life. There is no meaningful security to speak of.<p>If I handed a unlocked "Linux phone" to somebody and said "take a photograph of me"... The chances of that actually working is slim to none.<p>Meanwhile we have Android OS that is proven to work. It is open source. It is used by, literally, billions of people. The security model is as good as it gets. It has better application support then Windows.<p>Taking something that works and then making it more secure and more open and more privacy focused is infinitely more productive and meaningful then trying over from scratch because you want a phone based around Nix packages or whatever.<p>Even if Google decided to close source Android from now on and be actively hostile to any open source kernel modules... Forking the Android that exists today and trying to make it work is exponentially more likely to yield positive results then, say, starting on a Debian-based "Linux phone OS".<p>And Android can still use nix-pkgs if you really wanted to.
The whole point of Linux is that everything is open and, with enough work, can be built upon. I don't want to have to reinvent my software (I'm refusing to say app because truly, its a boogeyman term) for another form factor beyond UI. Having a not-Linux phone means I need to. I brought up nix because I'm invested in the community and know some people who care about making software truly work on other platforms.
> there is no such thing as "mainstream Linux"<p>Yes, there is: <a href="https://linux.org" rel="nofollow">https://linux.org</a> (aka mainline Linux). You can have various DEs on top of it, but the main functionality depends on the drivers in the mainline Linux, not so much on the DEs. Most of the operating systems for Pinephone listed in your link have more or less the same problems and features, because they all use the same kernel. They all depend on the upstreamed support of the device.
AOSP is Linux.<p>If by "mainstream" Linux you mean something like postmarketOS, I'd suggest you look up reviews or give it a try yourself. A few months ago, people were reporting a hard time placing a call, taking a photo, etc.