>At the time of writing, within ~12 months, in 2027, the 2027 Signature, Razr fold, and Razr flip will meet the hardware security requirements and should have official GrapheneOS support.
Motorola is currently porting GrapheneOS to their devices.
I knew it would be their higher end devices but I really wish they would have put it on their lower end as well.
I have a Moto G running LineageOS and it's my favorite phone ever. The ability to have my 800GB of music synced to a sdcard is something I'm loath to give up.
Motorola's flagships are going to be their first devices providing the updates and hardware-based security features required by GrapheneOS. It will come to lower end devices but it will take longer.
Snapdragon 8 Elite Gen 5 is the first Qualcomm SoC with hardware memory tagging (MTE). MTE isn't even available on the slightly lower end Snapdragon 8 Gen 5. A lot of the SoC security features are segmented based on price and only the flagship SoC platform has everything we need. Snapdragon's upcoming next generation SoC is the first truly providing everything we need. There's still a lot of work to do since providing the features on paper is different from having those fully integrated to match what we have on Pixels.
Replying to you here in hopes you see this question.
I'm one of those people who is affected by PWM on OLED screens. I tried a Pixel 9 Pro XL and it didn't work for me. Have a Razr 2024 which mostly works and that's thanks to some custom PWM settings from Motorola.
Will Graphene OS have these custom PWM mitigation settings on 2027 Motorolas?
If anyone runs across this comment in the future, the answer is: YES. On Mastodon, they told me they will have full support for Motorola's custom PWM settings.
I had Motorola Moto Gs all from the first generation to the fifth or sixth, cheap and worked great, had everything one could wish for in a daily smartphone. But eventually they too started growing in size, and so I got an iPhone 12 Mini instead, that I still use to this day. I'm currently hoping I'll find something released in 2025+ that is the same size as the Mini or the old Moto Gs, but they are nowhere to be found...
I think I'll buy one of those new Motorolas with GrapheneOS just to hopefully vote with my wallet a bit, and make them port it/use it for more phones in the future, which just maybe might eventually be a "normal" sized phone again.
We want to support cheaper devices too but flagships will be the first ones meeting all of our update and security features requirements. Providing hardware memory tagging (MTE) and a good enough secure element with the modern AOSP APIs are the main requirements for hardware security features.
Snapdragon 8 Elite Gen 5 is the only current Snapdragon SoC with hardware memory tagging since even the slightly lower end Snapdragon 8 Gen 5 didn't provide it due to being developed a bit earlier despite being launched later. They tried to provide it for both but didn't get it fully working in time. The next generation makes major secure element improvements. We potentially could have supported a Snapdragon 8 Elite Gen 5 with a secure element from another company but there wasn't enough time and the next generation is a lot better in multiple ways. There's still a large amount of porting and integration work remaining to do.
We need the devices to meet our requirements so that's the main limitation. The current generation Snapdragon 8 Elite Gen 5 is the only one providing hardware memory tagging (MTE). Even the slightly lower end Snapdragon 8 Gen 5 doesn't support MTE. The next generation flagship SoC has improvements needed to meet our requirements. There's still going to be a lot of porting and integration work. We'll be the first ones using MTE for the whole kernel and OS as we are on Pixels so there's going to be a lot to deal with for it. For Pixels, Google did do testing for MTE across the OS internally but even on Pixels it isn't perfectly supported and we have to fix a lot of memory corruption bugs it finds in both the kernel and userspace.
I would bet that what Motorola can change without trouble on the lower end is more restricted, too. Generally low end models use more parts that are old, off the shelf, and/or shared with several other models to keep costs low, and so major changes can quickly balloon costs.
> Lower end devices will take more time to meet our requirements since the updates and security features aren't as good. It's mostly due to how Qualcomm handles it. The latest Snapdragon flagships have the best security features. We'll also need Motorola to start paying them for longer updates below flagships
I really wish more artists would put their music on band camp. I have even noticed that some artists who used to put their albums up there no longer are. It's a real shame
For discovering new music, I listen to my old college radio station. About once a month they play something good that makes me do a deep dive. I use Pianobar while I work, and creating a station based on a new (to me) artist tends to give me more to explore. I also use music-map.com from time to time.
As for acquiring music, I use Bandcamp. If they aren't on there, I'm not above finding it via file sharing.
I have a bunch of python scripts that help me rename all my files once I get their tags sorted out. For that I mostly use AudioRanger because it's so simple and I only process one album at a time.
From there, I use Syncthing. But I'm thinking about replacing it with rsync and just kick it off manually when I want to update everything about once a month.
For autotagging and importing (moving files), Beets.
For tagging edge cases, MusicBrainz Picard as the GUI and the Python tagging lib underneath it (mutagen iirc) with an LLM inside the pi cli agent for automation.
For format conversion and copying to portable devices, ffmpeg in custom bash scripts managed by an LLM.
We should be able to support the next generation of the Razr Ultra. It will take longer for the lower end devices to meet our requirements for updates and hardware-based security features.
We should be able to support the next generation of the Razr Ultra. It will take longer for the lower end devices to meet our requirements for updates and hardware-based security features.
We think folding devices are a lot more useful and likely to get more users but we already have those via Pixels so flip devices are compelling as a new form factor. We're also interested in having support for new tablets.
New tablet support is very compelling! The Pixel tablet hardware is... passable... but Graphene on something more refined would be amazing! Especially something with a keyboard cover available (no idea if Motorola does this).
How is the crease on the flip? On some of the foldables like the samsung's, the crease is pretty noticeable and for me it bothers my OCD a little bit. I love the idea of a foldable though
I've got one of the Samsung flips and had thought it'd bother me as well, but it's not very noticeable unless you're dragging your finger across the screen, and I've eventually stopped noticing it at all, and notice screen smudges much more readily. Earlier flips were worse with that though. Unfortunately I haven't played with the Razr so don't know it compares. Definitely play around with one in person at Costco/Best Buy/Target/Walmart/wherever before committing though.
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.
* before replying snarkily that Android is Linux, please take a long walk off a short pier, thanks
Most European banking apps work on GrapheneOS. Many support tap-to-pay on GrapheneOS which is unique to Europe. Curve Pay is a financial service supporting tap-to-pay on GrapheneOS in the European Economic Area and UK. PayPal has tap-to-pay and permits using it with GrapheneOS but it's only available in parts of Europe. It's the rest of the world where tap-to-pay on GrapheneOS is an unsolved problem but that can and will improve.
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.
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.
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.
This type of post is why I come to hackernews. Up until now I've been depressed that we don't have a proper "Linux" phone os, but your explanation has properly laid bare the reason why that's a bad idea.
2. A subset of existing apps will refuse to run on various shades of non-stock/unofficial system.
I pointed out that 1. the existing apps largely do 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.
If I cut down your page of text to the relevant points, I believe it amounts to:
1. GOS has better app compatibility than waydroid.
2. GOS is supported by some apps that would refuse other non-stock systems.
3. GOS is more secure/private. (This is unrelated and should at most have been a reply to the root comment.)
On 1. compatibility, yes you're probably ahead, though I have to question how much since waydroid is also 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?).
> 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.
Android has a massive app ecosystem including the largest open source mobile app ecosystem. Those apps are nearly entirely available for GrapheneOS. Very few apps are unavailable for GrapheneOS. It's nearly entirely banking and government apps, but as we said 90% of those work on GrapheneOS.
AOSP and GrapheneOS have hardware-based virtualization usable to run desktop Linux software. It even provides opt-in GPU acceleration with gfxstream and will likely have native GPU virtualization support similar to NVIDIA's paid vGPU in the near future. AOSP and GrapheneOS have a very usable desktop mode which will be getting much better. Android is replacing ChromeOS and was already heavily improved for desktop use as part of being included within ChromeOS. We have that app ecosystem available too.
> the existing apps largely do run on other Linux systems via waydroid
A large portion of Android apps do not work via Waydroid. It has drastically lower compatibility than GrapheneOS and there are fundamental issues with how it approaches it.
The approach they take also severely harms privacy and security through throwing away most of the privacy and security model used by Android. That would not be the case for running AOSP in a hardware accelerated virtual machine, which is what we would recommend doing. It would still have greatly reduced compatibility due to apps using hardware APIs such as the hardware keystores and many apps actively trying to stop themselves being run in a virtual machine or other weird environment. It would work a lot better than using namespaces but would require modern hardware with virtualization acceleration.
> apps refusing to run on non-stock systems are likely to refuse GOS as well
A very tiny subset of overall Android apps entirely ban using a non-Google-certified OS. Most only have checks for the security model being intact and anti-tampering code interfering with running the apps in an atypical environment. We run into these issues with our privacy and security hardening features so we've done a lot of work to maintain compatibility.
> GOS is supported by some apps that would refuse other non-stock systems.
GrapheneOS exceeds all of the security and attestation expectations of these apps. They have no reason to ban using it and we make sure to avoid that being the case. It's only a tiny number of apps banning using GrapheneOS in the first place and a growing number of those are beginning to permit it since they don't actually have a reason to ban it. They do have a reason to ban an OS not providing the security model and attestation functionality they want. We disagree with attestation being used this way, but they can do that while supporting GrapheneOS and a growing number of these apps are doing so.
It's a fork of outdated LineageOS with a compatibility layer to make it run as part of a non-AOSP host OS. It has SELinux disabled which means the app sandbox and other protections aren't intact along with many other major differences. Apps can see these differences and many apps ban it because they can see the security model isn't intact or detect what's happening as a form of tampering.
In practice, GrapheneOS only gets banned by services enforcing the Play Integrity API device or strong integrity level without permitting GrapheneOS via hardware attestation. A growing number of apps are permitting it since they don't have any real reason to ban it. It's easy for them to stop endless negative reviews and customer support complaints from GrapheneOS users by simply implementing Android hardware attestation with Google's open source library for it and permitting GrapheneOS. They can also simply delete the code banning using non-Google-certified operating systems which is what we'd prefer over them hard-wiring permitting GrapheneOS and specific other alternatives.
> yes GOS has gotten some buy-in, but if 90% is good enough
That was only about banking apps. Over 99.99% of overall Android apps work on GrapheneOS. The vast majority of apps are not banking or government apps.
> compatibility as your advantage
It has an immense compatibility advantage along with far better privacy, security, usability and battery life.
> 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
Most users have 100% compatibility since most people don't use the around 10% of banks banning GrapheneOS. Our userbase is also growing large enough that apps cannot ban using it without it being a huge hassle for them. They have no actual reason to ban it, so that's why a growing number of apps are removing the ban on using it. They're usually not willing to stop using the Play Integrity API but once this is on their radar due to complaints they often become willing to implement using the Android hardware attestation API to permit GrapheneOS and other alternatives meeting their requirements. It's not a full solution since it won't allow people's self-signed builds or forks of GrapheneOS but it's progress and it enables the apps to easily permit more operating systems in the same way. They can just add more to their list. We would prefer the Play Integrity API being banned by regulators but this is good enough for now.
> since GOS is missing vitally important features compared to other Android ROMs let alone "normal" Linux systems
GrapheneOS has similar functionality to mainstream Android smartphones. We highly prioritize providing missing functionality not available through apps.
GrapheneOS is an operating system, not read-only memory firmware. There's a boot ROM which loads the main boot firmware from the SSD, verifies it and transfers control to it which then does the same with the OS. GrapheneOS is simply a regular OS installed on an SSD. Verified boot protects it from modification but it's not in read-only storage or anything like that. We don't misuse the term ROM to refer to it and prefer if others avoid it too.
> how long has GOS been without full backup functionality now?
GrapheneOS has much better backup support than the stock Pixel OS and most Google Mobile Services Android devices.
GrapheneOS has a built-in encrypted backup system. It backs up the same data as Google's device-to-device transfer for moving between Android devices. Every app targeting Android 12 or later gets backed up since allowBackup="false" was redefined to only disable cloud backups. Every Play Store app has been required to target Android 12 or later since under a year after the release of Android 12. The issue of apps opting out of backups has been in the past for years.
Backing up more of the system settings and other system data is planned and requires gradually expanding what gets converted into a portable format transferable between devices and OS versions.
> What other secure options are those?
It's up to these companies to define their security requirements. GrapheneOS is far more secure than anything permitted by the Play Integrity API device or strong integrity levels. It supports hardware-based attestation and we publish a signed JSON object providing our verified boot key fingerprints for use with it. They can easily use that and permit GrapheneOS. Other operating systems preserving the Android security model can do the same. Once they allow GrapheneOS, it's easy for them to allow more in the same way. It would be nicer if they stopped using the Play Integrity API and left OS security up to users but most of these apps are not open to doing that. A small portion of apps adopting the Play Integrity API didn't understand what it does and are willing to stop.
> We would prefer the Play Integrity API being banned by regulators but this is good enough for now.
Unfortunately, the EU is currently developing their age-verification-app, and it mandates hardware attestation[1], and it seems that their reference implement those requirements using Play Integrity[2].
Our growing userbase and Motorola partnership will give us a lot of sway to get apps to allow GrapheneOS. We can't realistically convince banks, governments and other companies to stop requiring attestation. We can realistically convince most apps to allow GrapheneOS via hardware attestation since it supports doing it via the standard Android key attestation API. We cannot realistically convince apps to not adopt attestation unless they implemented it without truly wanting what it provides which is unlikely for service-side integration. We've only convinced a couple apps to stop using the Play Integrity API. However, we've convinced a growing number to permit GrapheneOS alongside permitting Google-certified operating systems.
Regulators should force Google to stop further closing up Android and to permit alternate operating systems to pass the Play Integrity API device and strong integrity levels. It should not require certification by Google and complying with their arbitrary requirements based around their business model. There should be another path to obtaining certification without Google's involvement where Google has to respect it and permit those devices and operating systems to pass. Most important is stopping them from closing things down more against the original terms they provided Android and gained market share with it. Next most important is a reasonable path to alternatives passing the Play Integrity API based on security standards which do not block updates while waiting for certification.
We don't think it's realistic to stop apps adopting attestation but people should try regardless. A single country with a large market banning would make a huge difference.
https://grapheneos.org/articles/attestation-compatibility-gu... is our guide for app developers on permitting GrapheneOS via hardware attestation. Other operating systems can publish signed keys in a similar way to enable easily supporting them once this is implemented. An organization certifying operating systems could collect these and sign an overall list. It would also be possible to support a broader hardware ecosystem with alternate roots of trust by providing a signed list of those too. This is not the future we want but it is the future we believe we can obtain through a lot of pressure. We would greatly prefer apps not making an allowlist of operating systems. People should be able to make their own GrapheneOS build and use the same apps.
It's not a very good guide, frankly. It's basically a wall of text without clear instructions on what to do, besides "look at the examples Google gave". And even looking at Google's examples, there are no examples or explanations that tell me how to download the list of allowed signatures, and what should I do with the Json schema.
> Android has a massive app ecosystem including the largest open source mobile app ecosystem. Those apps are nearly entirely available for GrapheneOS. Very few apps are unavailable for GrapheneOS. It's nearly entirely banking and government apps, but as we said 90% of those work on GrapheneOS.
> AOSP and GrapheneOS have hardware-based virtualization usable to run desktop Linux software. It even provides opt-in GPU acceleration with gfxstream and will likely have native GPU virtualization support similar to NVIDIA's paid vGPU in the near future. AOSP and GrapheneOS have a very usable desktop mode which will be getting much better. Android is replacing ChromeOS and was already heavily improved for desktop use as part of being included within ChromeOS. We have that app ecosystem available too.
There was really no need to write 2 paragraphs to agree with me.
>> the existing apps largely do run on other Linux systems via waydroid
> A large portion of Android apps do not work via Waydroid. It has drastically lower compatibility than GrapheneOS and there are fundamental issues with how it approaches it.
What is a "large portion"? It's worked fine for me but I suppose if you have hard data that might be meaningful. Could you describe the "fundamental issues"? My impression is that they just run the whole Android userspace in a container, which seems like a reasonable approach.
> The approach they take also severely harms privacy and security through throwing away most of the privacy and security model used by Android. That would not be the case for running AOSP in a hardware accelerated virtual machine, which is what we would recommend doing. It would still have greatly reduced compatibility due to apps using hardware APIs such as the hardware keystores and many apps actively trying to stop themselves being run in a virtual machine or other weird environment. It would work a lot better than using namespaces but would require modern hardware with virtualization acceleration.
Again, I know security/privacy is your talking point, but this isn't actually the argument at hand.
>> apps refusing to run on non-stock systems are likely to refuse GOS as well
> A very tiny subset of overall Android apps entirely ban using a non-Google-certified OS. Most only have checks for the security model being intact and anti-tampering code interfering with running the apps in an atypical environment. We run into these issues with our privacy and security hardening features so we've done a lot of work to maintain compatibility.
So, yes.
>> GOS is supported by some apps that would refuse other non-stock systems.
> GrapheneOS exceeds all of the security and attestation expectations of these apps. They have no reason to ban using it and we make sure to avoid that being the case. It's only a tiny number of apps banning using GrapheneOS in the first place and a growing number of those are beginning to permit it since they don't actually have a reason to ban it. They do have a reason to ban an OS not providing the security model and attestation functionality they want. We disagree with attestation being used this way, but they can do that while supporting GrapheneOS and a growing number of these apps are doing so.
Which is a lot of words to agree that yes, many apps only allow stock and therefor block you just like any other OS.
I'd like evidence for "drastically", but again we mostly agree.
>> waydroid is also 90% AOSP
> It's a fork of outdated LineageOS with a compatibility layer to make it run as part of a non-AOSP host OS. It has SELinux disabled which means the app sandbox and other protections aren't intact along with many other major differences. Apps can see these differences and many apps ban it because they can see the security model isn't intact or detect what's happening as a form of tampering.
Right. So it's 90% AOSP. Old AOSP with worse security properties, but for compat purposes that's not important.
> In practice, GrapheneOS only gets banned by services enforcing the Play Integrity API device or strong integrity level without permitting GrapheneOS via hardware attestation. A growing number of apps are permitting it since they don't have any real reason to ban it. It's easy for them to stop endless negative reviews and customer support complaints from GrapheneOS users by simply implementing Android hardware attestation with Google's open source library for it and permitting GrapheneOS. They can also simply delete the code banning using non-Google-certified operating systems which is what we'd prefer over them hard-wiring permitting GrapheneOS and specific other alternatives.
You and I have different impressions of how apps approach attestatoin.
>> yes GOS has gotten some buy-in, but if 90% is good enough
> That was only about banking apps. Over 99.99% of overall Android apps work on GrapheneOS. The vast majority of apps are not banking or government apps.
And most apps work on waydroid. Of course the apps that go out of their way to block non-stock are the pain point.
>> compatibility as your advantage
> It has an immense compatibility advantage along with far better privacy, security, usability and battery life.
(You've carved out 3 words in a way that doesn't make sense alone; this is part of either the previous or next bit)
>> 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
> Most users have 100% compatibility since most people don't use the around 10% of banks banning GrapheneOS. Our userbase is also growing large enough that apps cannot ban using it without it being a huge hassle for them. They have no actual reason to ban it, so that's why a growing number of apps are removing the ban on using it. They're usually not willing to stop using the Play Integrity API but once this is on their radar due to complaints they often become willing to implement using the Android hardware attestation API to permit GrapheneOS and other alternatives meeting their requirements. It's not a full solution since it won't allow people's self-signed builds or forks of GrapheneOS but it's progress and it enables the apps to easily permit more operating systems in the same way. They can just add more to their list. We would prefer the Play Integrity API being banned by regulators but this is good enough for now.
90% of the time, it works 100% of the time. Anyways, you aren't 100% compatible, so my point stands.
>> since GOS is missing vitally important features compared to other Android ROMs let alone "normal" Linux systems
> GrapheneOS has similar functionality to mainstream Android smartphones. We highly prioritize providing missing functionality not available through apps.
I'm not comparing to stock, and you refuse to give apps root access so the shortcomings that they can fix are limited. (Yes, I know your threat model demands that the stupid helpless users can never be allowed to control their device. That's actually defensible if security+privacy is your #1 goal, but it does undermine the features that your OS can provide.)
> GrapheneOS is an operating system, not read-only memory firmware. There's a boot ROM which loads the main boot firmware from the SSD, verifies it and transfers control to it which then does the same with the OS. GrapheneOS is simply a regular OS installed on an SSD. Verified boot protects it from modification but it's not in read-only storage or anything like that. We don't misuse the term ROM to refer to it and prefer if others avoid it too.
I love pedantry as much as the next guy, but ROM has not meant read-only memory in like 20 years.
>> how long has GOS been without full backup functionality now?
> GrapheneOS has much better backup support than the stock Pixel OS and most Google Mobile Services Android devices.
> GrapheneOS has a built-in encrypted backup system. It backs up the same data as Google's device-to-device transfer for moving between Android devices. Every app targeting Android 12 or later gets backed up since allowBackup="false" was redefined to only disable cloud backups. Every Play Store app has been required to target Android 12 or later since under a year after the release of Android 12. The issue of apps opting out of backups has been in the past for years.
> Backing up more of the system settings and other system data is planned and requires gradually expanding what gets converted into a portable format transferable between devices and OS versions.
So, you're trailing, say, Debian, and have done for years, and have at most a plan for someday being able to compete.
>> What other secure options are those?
> It's up to these companies to define their security requirements. GrapheneOS is far more secure than anything permitted by the Play Integrity API device or strong integrity levels. It supports hardware-based attestation and we publish a signed JSON object providing our verified boot key fingerprints for use with it. They can easily use that and permit GrapheneOS. Other operating systems preserving the Android security model can do the same. Once they allow GrapheneOS, it's easy for them to allow more in the same way. It would be nicer if they stopped using the Play Integrity API and left OS security up to users but most of these apps are not open to doing that. A small portion of apps adopting the Play Integrity API didn't understand what it does and are willing to stop.
So when you wrote "GrapheneOS and other secure options", you just meant GOS because nothing else matches your definition of security. Again, I don't exactly mind that, but it's disingenuous to gesture at other options that don't exist.
20% of apps from the Play Store not working as opposed to less than 1/10000.
> Could you describe the "fundamental issues"?
Many Android apps use functionality such as the hardware keystore APIs and other hardware APIs.
> My impression is that they just run the whole Android userspace in a container, which seems like a reasonable approach.
Using namespaces in the way they do is not a reasonable approach since they're running it with SELinux disabled which means most of the privacy and security model is disabled. It also isn't set up to run that way and requires very problematic hacks. It also ends up not being possible to run more than one instance of it due to those hacks.
> Again, I know security/privacy is your talking point, but this isn't actually the argument at hand.
It is not a 'talking point' and is very relevant in all cases. You may not care about it but most people reading this thread do.
> So, yes.
>
> Which is a lot of words to agree that yes, many apps only allow stock and therefor block you just like any other OS.
GrapheneOS has better app compatibility than plenty of Google certified devices. In practice, the only issues are with apps going out of the way to ban other operating systems and GrapheneOS does better than anything else. Apps are increasingly permitting it since it exceeds all their requirements and it's just a little bit of extra work for them to not solely depend on Google's API.
> I'd like evidence for "drastically", but again we mostly agree.
It's easy to check and other people have done so.
> Right. So it's 90% AOSP. Old AOSP with worse security properties, but for compat purposes that's not important.
No, you're wrong. It's very important for compatibility. Apps can and do detect large parts of the security model being disabled. A far larger portion of banking and government apps won't run on it. Having 90% compatibility with those is certainly better with 30% or less.
> You and I have different impressions of how apps approach attestatoin.
You don't have the experience and data we do. We have a large number of users and reports from them. We also have conversations ongoing with numerous banking apps about it and have seen multiple apps permit GrapheneOS. Revolut is currently talking to us, although the app works on GrapheneOS since we worked around how it was being banned in January 2025. We're also talking to Square (Cash App, etc.) and others. It is a problem which can be solved and these companies are largely not against solving it or even actively want to solve it, it just isn't something they've gotten to yet. The GrapheneOS userbase growing has begun to make this problem solve itself.
> And most apps work on waydroid. Of course the apps that go out of their way to block non-stock are the pain point.
No, a large portion of Android apps do not work with it because they use APIs unavailable or broken with it. Many banking and similar apps check that the security model is intact which it clearly isn't so they ban it but they would happily run on a non-stock OS which appears to have it intact.
> You've carved out 3 words in a way that doesn't make sense alone
What we wrote makes sense.
> 90% of the time, it works 100% of the time. Anyways, you aren't 100% compatible, so my point stands.
90% compatibility with banking apps is far better than less than 30%. You're trying to make it seem black and white when it isn't. Google certified Android devices don't truly have 100% app compatibility in the first place. Apps have plenty of required features, minimum Android version requirements, requirements for specific models (some apps only work on Pixels, Samsung flagships, etc.) and a lot more. Some low-end devices have broken support for Camera2 and other APIs despite the CTS. GPU drivers are buggy and games are buggy so there are compatibility issues. Perfect compatibility never exists. Nearly every non-banking app working fine and 90% of the special case of banking apps working fine is very good compatibility.
> I'm not comparing to stock
Most people are using OEM Android forks or iOS.
> and you refuse to give apps root access so the shortcomings that they can fix are limited
A userdebug build of GrapheneOS has root access. It's not suitable for production builds used by the vast majority of users and isn't in those. It's also incredibly niche and not very useful. What you're actually referring to is using a rootkit framework providing app accessible root access where a huge portion of the OS has root access. You're not talking about the user having root but rather a framework for apps built with disregard and even disdain for security being granted root via a dialog which a user cannot truly ever revoke or undo the consequences of granting beyond a reinstall of the whole OS.
> I know your threat model demands that the stupid helpless users can never be allowed to control their device
The app accessible root frameworks you're talking about drastically reduce the privacy and security of the OS for all users including ones never using it to grant root access to an app. Granting root access to apps built with such disregard for following security best practices is also not somehow unproblematic because you think they're trustworthy since they're open source.
> but it does undermine the features that your OS can provide
No, it means we build features with proper implementations following security best practices instead of doing it with half-baked hacks via a massive portion of the OS having full root access and granting that to apps.
> I love pedantry as much as the next guy, but ROM has not meant read-only memory in like 20 years.
It means read-only memory in embedded, information security and in the context of GrapheneOS which is an overlap of both. GrapheneOS works on security including boot security where it's very relevant. When someone says ROM recovery in the context of GrapheneOS, that means the boot ROM recovery mode loaded when firmware on the SSD can't be loaded. It does not mean the OS recovery mode. It's not correct terminology to refer to GrapheneOS. It propagates unnecessary misconceptions and confusion.
> So, you're trailing, say, Debian, and have done for years, and have at most a plan for someday being able to compete.
No, it doesn't provide a similar backup system portable across devices and major OS versions.
> So when you wrote "GrapheneOS and other secure options", you just meant GOS because nothing else matches your definition of security. Again, I don't exactly mind that, but it's disingenuous to gesture at other options that don't exist.
No, our response said the apps should set a security standard and enforce it fairly. They should not enforce Google certification but rather define the standard security expectations and permit anything meeting them. GrapheneOS is much more secure than any Google certified OS, so it would meet actual security standards they set. Whether other alternate operating systems meet those standards depends on what the app developers set as the requirements. Many Google certified operating systems won't meet reasonable security standards and would need to be banned if the enforcement is fair.
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 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.
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.
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.
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.
This is a meta comment, but I just wanted to thank you for your engagement and insight that you've shared throughout these threads. I personally get a ton of value out of it and really appreciate 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.
Interesting. Could you elaborate? I always thought that Secure Boot is reasonably secure (provided you can set it up in the first place).
The standard UEFI Secure Boot used with traditional Windows and traditional desktop Linux is an incomplete and insecure implementation of secure boot. It doesn't verify the vast majority of the OS, nearly always lacks an unbroken chain of trust from the hardware, does not verify all of the firmware and lacks downgrade protection for both most of the firmware and the OS. In the typical setup, it trusts an enormous number of keys and software. It barely provides any useful security properties.
Secure boot was widely used as a term prior to the UEFI usage of the term including many much more meaningful implementations. The term verified boot refers to the same concept but avoids it being confused with solely verifying a late stage bootloader and OS kernel from UEFI firmware.
Ah yes, so if I understand correctly, you're referring to the fact that, e.g., on Linux a typical Secure Boot setup will verify the kernel (if at all) but not the rootfs. Yes, that's of course a huge issue (as is mutability of the rootfs in the first place). I think what I had in mind is indeed more akin to the "verified boot" setup you described.
I haven't tried using Wade Droid on a phone, but on a fedora desktop it is a little bit rough. It takes a lot of finagling to get anything that requires Google services running, and that is a surprisingly huge amount of apps that people want
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.
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.
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?
Good for you. Nobody is challenging what a web app can or cannot do. I love PWAs but services I need every day either don't have a web interface at all, have limited features or are unusable on a small screen let alone having a PWA. This is not about technical abilities but about what companies actually do.
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.
This is true but the problem is every now and again some of us have to deposit a cheque because even if we would love for cheques to go the way of the Canadian penny they are very much still a thing
No you cannot, as of yesterday. The mobile app doesn't even allow your choice of camera app, to avoid even the tiny amount of fraud that doing so might enable.
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.
Yep. Everyone here is talking about "just use the website" but ANZ Plus, a "neo-bank" which is increasingly popular here in Australia, literally has no web portal.
Its app is really nice and native, though. That, along with a decent interest rate, is why I use it.
> What's stopping me from using a browser to log in to my bank?
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), https://seg.bb.com.br/home.html is the diagnostic page for that "security module" (the FAQ page there has links to the installers).
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).
The relevant regulations are Commission Delegated Regulation (EU) 2018/389 and the earlier Directive (EU) 2015/2366.
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).
That, in and of itself, wouldn't be a problem. The way most banks implement it, however, is by giving you two choices:
1. You use their mobile app (which likely requires device attestation and Google Play Services, so won't work on a plain LineageOS install)
2. You use their CardTAN device, which is extremely inconvenient to always carry around.
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.)
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.
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".
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.
Where I live, the overlap between banks with physical branches and those that don’t require an app or cardTAN is nonexistent - genuinely zero. But maybe I’m just old-school for wanting to have the option to visit a branch.
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.
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.
You're basically out of luck. This is happening all over the world these days with various government services.
It's not just for clients with no smart phones. It's also clients who activate developer mode on their smartphone etc... clients who use VPN. Clients who run AdBlocker. Clients who use Firefox.
There needs to be a severe push back against this.
Things have gotten so crazy that the homeless here are walking around with QR codes printed out when begging for money. I'm guessing they're a network of people who share the same smartphone/payment method..
I am so grateful for the large religious population in my country who eschew the smartphone. I suppose because of them every back and government service is available to all citizens.
@fsflover: and my mobile phone provider. And my insurance. And my eletricity provider. And my housing associations customer portal. Getting doctors appointments. Mortgage. Union. National retirement savings account. Some of these may have some alternative left, but far too many you will be left out.
Well, I can buy a train ticket without it, so I could still leave.
Do you mean to say that all these services require strong device integrity to function in Sweden?? In Australia, no local app that I'm aware of (banking, finance, government, medical) requires any form of device integrity - otherwise I couldn't use them. The only exception I've encountered is Google Wallet.
I wonder why there would be such a difference in policy between countries, not only in government but across the private sector? This doesn't make any sense to me. If anything, I'd expect Sweden to have a more sensible, left wing attitude than Oz.
The comment that I was replying to was suggesting (to me) to live in sweden without mobile bankid (centralized 'banking' 2FA app on smartphone). I have here listed services that require said mobile bankid. Mobile bankid works for me and others on graphene os, but would likely not work on an arbitrary linux smartphone.
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.
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.
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.
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.
Almost none support strong dedicated HW authenticators or second factors. Not even as an option to those who care.
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!
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.
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
There are things that you just can't do with wasm. wasi was designed to fill the gap. If you can remember, wasi was all the craze right before AI came out and suddenly it just faded in the background.
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".
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.
I'm guessing the companies will continue to be difficult, but it'll be amusing to watch, at least.
Yep. Had to change banks because of my old one suddenly dropping grapheme support by adding stupid attestation mechanics.
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.
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.
It's not invasive generally speaking. My healthcare provider allows me to access e-perscriptions via the app. But for that there are certain security requirements which this particular Healthcare provider equated to "Android good, GOS bad"
> My healthcare provider allows me to access e-perscriptions via the app.
Why can't the prescription be sent to email or collected on a website? I don't see why an "app," especially one signed by Google is necessary for something like this. It wouldn't surprise me if the app requested location or sensor access in order to provide a "personalized experience."
90% of those apps do work on GrapheneOS. A growing number are adopting the Play Integrity API but a growing number with it already implemented are choosing to also permit GrapheneOS.
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.
Traditional desktop Linux heavily involves big tech companies including IBM (Red Hat). AOSP has a massive amount of non-Google companies and individuals working on operating systems based on it. It would survive without Google.
You're misinformed about security preview patches. It has nothing to do with Google being hostile. Additionally, our security preview releases have regularly included patches for components not specific to Android such as wpa_supplicant prior to those being publicly disclosed by the upstream projects.
> Traditional desktop Linux heavily involves big tech companies including IBM (Red Hat).
Yes, for some definition of "heavyly" that you chose. Yet no single megacorp can decide single-handedly on the future of Linux or do this: https://news.ycombinator.com/item?id=49364745
> AOSP has a massive amount of non-Google companies and individuals working on operating systems based on it.
Can you define "massive" in, e.g., percentage of lines of code? This looks unsubstantiated to me.
The parent has a good point and shouldn't be flagged.
> AOSP has a massive amount of non-Google companies and individuals working on operating systems based on it.
based on is the important part here. Yes, AOSP would survive without Google. But as long as Google is in control of AOSP, it controls the direction in which AOSP and all downstream projects are headed. Because of breaking changes in AOSP, there is a cost in maintaining downstream changes. So downstream projects cannot veer off too far, short of a hard fork.
> You're misinformed about security preview patches. It has nothing to do with Google being hostile.
Does it not? From the 2025092500 GrapheneOS release notes: "We strongly disagree with broadly distributing patches to OEMs 3-4 months before the official publication date. It further delays getting patches to users and sophisticated attackers will have no issue getting the patches from one of many people at Android OEMs with early access."
I believe the timely security patch issue will be resolved with the Motorola phones due to the OEM partnership.
Long term in the future, surely the open source community forks AOSP itself and maintains it. The worst option would be giving up and trying to focus on Linux (desktop) imo.
Well, if you want a mass market device that runs Linux, you have to meet the market. Otherwise we can start tracking 2525 as the year of Linux on the smartphone. If man is still alive.
The concept of a mass market device is sort of incompatible with the freedoms we generally associate with linux -- Android is really the closest thing we can hope for. It runs a linux kernel, a very non-standard userspace, and is relatively locked down (when compared to a general purpose linux distribution)
I think "linux smartphone" would end up looking very similar -- some UI on top of a kernel with a very non-LSB userspace; therefore the concept is really not all that compelling
Because there are only a few people who actually build this kind of software and if they cant agree how it should look. No projects will have the dev power to come out with a solution.
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.
You can strongly disagree but it doesn’t change the fact that the comment by the OP is objectively true.
Especially in this political climate it’s insane to recommend people switch to a phone OS that can be pwned via hardware or software means in virtually zero time versus something like GOS + a Pixel or an iPhone.
Can all the Linux servers also be pwned in no time? This is a huge exaggeration. This requires the users to know what they are doing and running -- with this I agree. But it's doable today.
The hardware and software security of Android/iOS/iPadOS/GOS devices are leagues ahead of Linux servers in all aspects and it’s not even close (but they also serve different purposes so to some extent I’m not sure how 1:1 this comparison is). However, this discussion focuses on desktop style Linux distros which is what these phones are running which have inadequate security. Desktop Linux is inferior security-wise to a server environment where each process/app is running as it’s own user etc. Desktop-style Linux phones also have virtually zero hardware security versus the alternatives.
It doesn’t matter if a user knows what they are doing. For example installing so-called “trusted” apps means they’re only trustworthy at that moment in time and not forward-looking. All it takes is one supply chain or runtime security exploit. Software security is also extremely poor with a lack of comprehensive sandboxing and so on, I would just read the grapheneos accounts replies on here since they’re writing entire novels on this.
I mean even GrapheneOS shows how relevant this is with Samuel Tunick, on the front page today. If he’d had a desktop Linux phone that was seized from him while in AFU, sure it would be “private” but there would be virtually nothing stopping officials from running through his entire phone since so many of these desktop Linux distros rely on poor security elements if any on top of FDE with LUKS so your entire device is basically exposed and unencrypted after the first unlock.
This whole comment was borderline stream of consciousness so I apologize if anything is unclear here.
You mean Microsoft proactively kept shooting devs in the kneecaps?
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.
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)
The advantage being, we can manage packages using a regular Linux distro
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.
> The advantage being, we can manage packages using a regular Linux distro
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.
You can't because a lot of apps check that the phone is controlled by Google with Play Integrity.
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.
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.
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.
They did end up releasing Windows Subsystem for Android via the Windows Insider Program, which was enough for the OSS community to take it over after it was abandoned. It still exists and has worked quite well for my use case: https://github.com/MustardChef/WSABuilds
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).
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.)
AOSP even without the GrapheneOS improvements has drastically better privacy and security than a traditional desktop distribution. A mobile Linux distribution with a much better privacy and security model than traditional desktop Linux is still Linux. A similar approach can also be used on a laptop or desktop too.
Cheers, thanks for all the work you do on the project.
There is still a philosophical reason for supporting a version of Linux for mobile devices that is not dependent on Google, but is community-driven, for users with different priorities.
That is not really relevant to the GOS project though, and the fact that GOS is probably the easiest way to get a Play Services-free mobile device kind of drags it into discussions that it doesn't necessarily belong in.
Again, thanks for your work, and I appreciate your team's focus on your goal of the best security possible.
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?
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.
AOSP even with the GrapheneOS improvements provides far better privacy and security than a desktop distribution. Those are the hardest things for a desktop OS to accomplish since they cannot force the whole software ecosystem to conform and very few developers care about it. Developers largely treat their own code and dependencies as trusted. Few developers are inclined to heavily invest resources in limiting their own access and capabilities. The baseline sandbox provided by AOSP enables the GrapheneOS improvements because of how much is standard.
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.
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.
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.
It also has many other advantages including the OS and app ecosystem heavily using memory safe languages from the beginning, which has greatly increased over time. The majority of new code added to the OS has been in memory safe languages for years. Android is replacing Java with Kotlin and C++ with Rust but it was always using a lot of Java and moved to using ahead-of-time compilation for it with Android 5. It then moved to a more complex way of compiling it but GrapheneOS has kept using ahead-of-time compilation.
It has much better adoption of modern exploit protections and far better testing with sanitizers for both the kernel and userspace. It enables us to do even better because most of the memory corruption bugs caught by MTE are resolved. We do still need to resolve more, but it would be far more impractical for us to do it on the desktop.
Android uses SELinux for both whole system MAC and MLS policies with deep OS integration. It uses it for a massive amount of kernel attack surface reduction with allowlists for socket protocols, devices, ioctl commands and other functionality. It's far different from the traditional targeted approach used by desktops or even rare use of whole system SELinux for desktops/servers. It's nearly a completely different thing in practice. The OS has it deeply integrated in userspace for enforcement beyond in the kernel and it's developed around it. It's the main basis for the app sandbox and a lot of other isolation in the OS. OS processes are specifically split up and have IPC set up in a way that they can be contained well with it.
The mandatory app sandbox with yearly backwards incompatible privacy and security improvements as part of new target SDK versions is the most important difference. It's the basis for GrapheneOS being able to do much better. Having the infrastructure it already has available means we can add our features such as Contact Scopes, Storage Scopes and our Sensors toggle on top. We plan to add a lot more, but there are also the yearly improvements we get in the baseline such as how Camera, Microphone and Location have supported one-time grants for years, can only be used while apps are in use once granted (with Location have an extra layer of background opt-in) and precise vs. coarse location.
AOSP on a Pixel without the improvements made by GrapheneOS is far more private and secure than desktop Linux. The starting point is far more secure than the hardware, firmware and software of the desktop ecosystem. It has a far better privacy model too. GrapheneOS does heavily improve the permission model, exploit protections and much more but the starting point was already much better.
Seems like it's the same problem as chromium. Is it better to get off the Google controlled ecosystem? Yes. Is it easier to leverage the Google controlled ecosystem? Also yes.
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...
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.
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.
This is not a good example. Pinephone Pro had a very small developer community (of volunteers) and thus quite undeveloped software. It was discontinued for this reason. Librem 5 and Pinephone are usable as daily drivers, albeit they do require compromises.
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.
Android is a massive operating system family and exists without Google Mobile Services in the OS. It's entirely possible to turn things around in terms of Google gradually taking more control from OEMs and squeezing out competition.
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.
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.
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).
Because it's a mobile platform and "GNU+Linux" is laughably terrible in this space.
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.
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).
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.
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.
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.
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.
> but devices like the Steam Deck prove that mobile linux isnt as much of a problem re: userspace as you claim.
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)?
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.
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.
GrapheneOS is a non-profit open source project. We provide documentation and other information on the project.
> Android is not a Linux distro nor is it directly derived from Linux
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.
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.
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.
> Mobile phones are not "personal computers".
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.
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.
> Trying to act like it being "mainstream" or "common" relative to desktop distros matters is just laughable.
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.
> And I take issue with the notion that a monolithic kernel cannot be secure.
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.
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.
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.
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.
> then why arent you guys working on the next kernel for personal and high-performance computing
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.
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.
> In the future, I'd recommend replying on your own account rather than an organization sockpuppet. Thanks!
We're using a project account making it clear these responses are from the GrapheneOS project. That's the opposite of a sockpuppet account. We've moved to using this project account instead of individual accounts because of personal attacks directed towards our team. A community member created this account and transferred it to us to encourage us to keep posting on Hacker News.
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.
well, apparently not even Microsoft had enough capital.
It's almost like the free market only works when we have well-defined and regulated markets. 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!!"
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.
> I've never really understood why we chase Android-alikes on mobile platforms instead of trying to build on mainstream Linux.
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.
I mean you invoked "mainstream Linux" and "Nix" in the same paragraph. That alone should clue you into why this, absolutely, does not work.
"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.
I mean... In that page there is no less then 25 different "Linux Phone OSes" listed.
None of them actually work.
They are all going to be slow, they are all going to burn through battery life. There is no meaningful security to speak of.
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.
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.
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.
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".
And Android can still use nix-pkgs if you really wanted to.
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.
A year ago or so, the ThinkPhone 23 (Snapdragon 8, 2023, a weird "flagship") was available for 229€ new on various retail stores. The phone also supports Mobian/PostmarketOS and the bootloader is unlockable with no adverse effects.
Out of nowhere, it received (along with other older phones) updates up to Android 16.
I wouldn't be surprised if the "sudden" update was just a side effect of Motorola preparing for Graphene to be released on these older phones.
I have a 'long life' Android device (Zebra EM45) that has only recently gotten its Android 15 updates; its committed through Android 16 so I assume it's also waiting on Qualcomm to get its act together and in gear for whatever final patches are required for the QCS5430. IIRC, QCOMM is promising "10 years" on the CPU.
I bought the Moto signature a month ago , I already assumed it prolly won't support graphene, since some of the previous replies on X indicate that the graphene team requires full hardware compliance with their requirements, and the Signature apparently is not compliant yet.
Anyway I ended up buying a really good smartphone.. just not a graphene supported haha :(
Also this is really great collab from moto & graphene as more vendors will officially recognize Graphene as legit OS (legel/OEM is different concept). I heard month ago Volkswagen banned graphene, hopefully we we will see moving things in opposite direction...
They didn't "ban" them, but they did enable some attestation feature that effectively "bans" anything that isn't Google Android.
Which still makes you wonder why Volkswagen is so keen on alienating what little is left of their customer base with completely stupid security theater.
Because the EU is run by lawyers and lawsuits. They probably decided there was a risk of being sued for insufficient security if they didn't enable every security feature, and they considered it as zero impact to customers because nobody uses graphene.
Yes, but that is still very confusing to me, because you're not paying other people money so that they just follow incentives without thinking, vision or backbone.
The whole idea of buying something is giving people money for their (assumed correct) judgement, which then leads to desired artifacts downstream.
It's fair to say they banned GrapheneOS but they didn't only ban GrapheneOS. It's very rare for apps to specifically ban GrapheneOS but Revolut uses an SDK which tried to do it. We worked around it and Revolut works on GrapheneOS since January 2025 but not for lack of trying to ban it by an SDK they use and it sometimes blocks our users.
They banned GrapheneOS and other non-Google certified operating systems.
> Volkswagen probably don't even know that you exist.
They're aware of the existence of GrapheneOS. They've received immense pushback for banning it. They have customer support templates for responding to GrapheneOS user complaints.
> because like this it's just storytelling
Revolut shipped a check for ro.build.user being set to the string "grapheneos" resulting in using the app being blocked. They also banned the yellow verified boot state at the same time but quite notably did not ban the orange verified boot state. This was our release working around it to get the app working again:
We know what happened and what we had to do to work around it. It's verifiable that this was shipped by Revolut.
> I know of course that uncompromisingly maintaining something that challenges the status quo needs stories to keep the drive alive.
It's you who is pushing a false narrative.
> Idk man I think you people need grounding. That, or I just need to stop seeing the humanity in you, start seeing you as a software vending machine and applaud your (hate to say it, but) delusions, as those lead to you working harder for stuff that is useful to me.
You're not welcome to contact us again after this.
The people at VW don't think about the customer. They are essentially bureaucrats who only live to expand their personal fiefdom in the bureaucracy. I bet that many in the IT-security team would insist that their team doesn't have customers.
I just wonder how they handle full Google's certification for hardware integrity + Google Play Store with GrapheneOS. They contradict on this part on the normal GrapheneOS mod and I don't see a way how they will not on Motorola phones.
Banking apps (e.g. Revolut) block GrapheneOS actively and many other apps too.
But it will be interesting times once they are out!
> Banking apps (e.g. Revolut) block GrapheneOS actively and many other apps too.
You've misunderstood something here. Revolut doesn't "block GrapheneOS actively". I'm running Revolut and most of my banking apps on GrapheneOS right now.
In my experience, there are two major categories of incompatibility:
- High levels of Google Play Integrity checks: app only works on releases of Android that have been allowlisted by Google. The only app that does this for me so far is McDonalds.
- Commercial root detection APIs: some of GrapheneOS' security features like "Secure App Spawning" trip root detection heuristics. This is the kind of incompatibility I usually run into for banking apps. You can disable individual features on a per-app basis these days to get around this.
When Google acquired motorola, I was excited at the possibilities. When they sold Motorola off, I thought it a deeply unfortunate move.
With this announcement though, I am now seeing it in a very positive light. Given Google's current position, if they still owned Motorola I can't see this sort of collaboration with grapheneos ever happening.
Major kudos to the graphenos team! This is a huge milestone, a huge accomplishment, and a real world validation of the incredible work that you are doing. Thank you so much for everything you have done
Lest you forget that modern computing exists because ATT built unix and then threw it out to the public, at speed, as they drove away from it as fast as possible. (Something about being an actual monopoly...).
There is at least one thing, on that list that I can almost assure you will be coming back (in concept and spirt) in the next 5 years. Likely open source, because google tossed it...
Meanwhile it has other very public and open winners: Golang, Kubernetes being two stellar examples of them not dropping something like a hot potato.
Yeah, its the "well, legally, we have to provide the source code, but we make it as painful and slow for you as we can without it becoming a blatant violation of the GPL."
GPL requires providing the source code via a medium customarily used for software interchange. Deliberately making it inconvenient by using a medium no longer customarily used for software interchange is a GPL violation. Google Drive is already an unusual way to distribute software.
Google is already failing to provide the Pixel kernel drivers in the preferred form for modification. Their kernel build system uses Git commands but yet they aren't providing the Git repositories it expects to be there. They had to provide a repo metadata file as a workaround but it's not the same since the revisions of the code aren't set properly in the resulting build.
Google is arguably already violating the GPL. They're deliberately making it inconvenient and are adding deliberate delays through requiring manual handling of the requests.
I'm pretty sure there is a lot of code in Android that belongs to Google and is not part of an upstream GPL project. They would be completely entitled to stop sharing it.
HE wants to get rid of forms, and make the rest of the world enjoy the burden of requesting access to open source code through a beloved form. Hope that's clear now.
> Prior to moving it to Google Drive, they started squashing the history into a single commit prior to pushing release tags. The tarballs provided via Google Drive have exactly the same source code. However, they went out of the way to make it more inconvenient in several ways.
Ugh.
Also I can't believe it's been 10 years since they shut down Google Code.
The repositories you have linked are not sufficient to build an Android distribution. In order to get the missing bits, you have to fill out a form: https://source.android.com/opensourcerequest and beg them, and if they decide you are worthy, they will email you a link to a tarball, which is hosted on Google Drive.
That's the mainline kernel. Actual devices use various LTS kernels, for instance the pixel 9a uses kernel 6.1[1], which was hasn't been updated in a year[2]
I'm not sure which one the latest update for the Pixel 9a is using, I have an older Pixel 8. When I look at the Settings -> Android Version I can see it's using a build from January 2026 (also 6.1).
Google hasn't been able to properly do / fix Android gesture navigation for more than half a decade now. The amount that edge swipes in things like photo editing apps are detected as backswipes (sometimes destroying 10+ minutes of editing) is laughable.
Technically this is because a lot of apps thumb their nose at the requirement to have safe areas around swipeable elements in their app, but as a user, that is not my problem to fix. It's Google's.
The workaround is so ridiculously easy too: only allow backswipes to count in the lowest 15% of the bottom left of the screen. Yet despite having hundreds of engineers earning ±350.000 per year work on this problem for years, they haven't been able to either implement or even think of it.
The real fix would be to deprecate the three button layout in Android 18 and remove it in Android 19. Force apps to comply.
The real fix would be to bring back physical control buttons and leave the touchscreen for the rest.
Also, I have 6GB of RAM in my phone - switching from a browser to youtube, or vice-versa, should not cause the other to clear and start back again from a freshly-loaded state.
350,000 a year and people can't even get basic things to operate properly. Google needs broken up and their engineers need to go back to the 90s and learn some real programming skill.
I think you are grossly minimizing the effects on your change on both users and developers. Neither are going to comply and then you have further fragmented the user base and removed a bunch of apps.
I use an Android tablet and I only backswipe at the upper left.
This is absolutely not a witch-hunt. People in that position wield enormous power and take their paycheck and responsibility that comes with it. Linking to his professional linked in relation to his responsibility is nothing but professional.
It's quite painful to resolve cognitive dissonance, so I understand the downvotes for your comment.
People are clever enough to reach high level corporate roles, but at the same time they're are too weak to emotionally process the consequences of their "work" on their human cash cows of below-average intelligence.
However with these kind of moral/ethical questions, it's really hard to draw the line.
Is working at Google and thereby facilitating the scamming of my grandmother worse than being an ordinary pickpocket or an lobbyist for big oil?
Public companies and their executives deserve the same treatment as the government and the politicians. It is completely fine to let them know that the people are upset with their decisions.
I get that you don't like Twitter/Facebook/Reddit or whatever, but a clear solution to this problem is to hurt googles public image as much as you can and for that you need a platform with as large of a reach as possible.
They post on Twitter more than anywhere else. This was a reply not a announcement or post. There are likely similar replies to this on their Twitter. Their communication is a goldmine for privacy and security info so even replies can be interesting enough to start discussion.
They have official chatrooms on Matrix and Discord and a forum on their website. They have unofficial (but run by them) chatrooms on SimpleX and Telegram and maybe other platforms idk.
They are not about avoiding big tech specifically, they make practical choices to improve privacy and security of their users.
This wasn't an announcement with any new information. It was a reply to a question with existing public information. We've repeatedly posted the same information on X in response to similar questions.
This is very exciting. I have been an iPhone user for the last 8 years. I am entirely in Apple's ecosystem.
I would legitimately change my phone (+watch +headphones) for a vertical foldable (like razr) phone running graphene OS. I don't think Apple is releasing a vertical foldable or even a modern smaller phone. One can only hope.
Anyone has any idea if this changes current situation with nfc payments? Currently many banking apps do not work, and google pay is just unavailable, to my understanding it was related to secure chip on phone - as graphene wasnt "stocked" android os approved by google, i dearly hope this chnages with motorola
Tap-to-pay is available on GrapheneOS via Curve Pay in the European Economic Area + UK, PayPal in parts of Europe and many European banking apps. Google Pay will likely continue banning using GrapheneOS for the foreseeable future until regulators crack down on Google's overall anti-competitive behavior with Android and Google Play.
90% of banking apps do already work on GrapheneOS:
A growing number of the apps banning using GrapheneOS are choosing to start permitting it. A small number of apps are permitting it by relaxing their Play Integrity API checks but most aren't willing to do that. A growing number of apps are implementing support for standard Android hardware attestation and permitting the GrapheneOS verified boot keys with it. We provide a page guide explain how to do that:
Our partnership will Motorola will help get the apps banning GrapheneOS to start permitting it through GrapheneOS becoming more mainstream and eventually being considered the stock OS on certain device variants.
Tap-to-pay is available on GrapheneOS in Europe. Your profile implies you're in the UK where Curve Pay is available. There are also banking apps in the EU with working tap-to-pay but we aren't sure if any of the UK banks provide it without Google Pay.
90% of banking apps do already work on GrapheneOS:
> If they worked on a dumbphone, I'd have a dumbphone.
A dumb phone won't provide any form of secure calls or texts. People should migrate away from carrier-based calls to the extent possible rather than towards it. A dumb phone is also entirely reliant on cellular instead of being able to use Wi-Fi instead.
"The initial devices with GrapheneOS support should be available in 2027. The initial devices will be flagships so they'll be higher end hardware than Pixels at a higher price. Lower end devices will take more time to meet our requirements since the updates and security features aren't as good. It's mostly due to how Qualcomm handles it. The latest Snapdragon flagships have the best security features. We'll also need Motorola to start paying them for longer updates below flagships."
I don't doubt they will cost more than the Pixel line, but I'm somewhat skeptical that the hardware will be higher quality. Perhaps my idea of what Motorola is capable of is outdated.
Google’s Tensor chipset is weak by modern standards, and Motorola is taking the strongest off the shelf processors from the best mobile chip designer (Qualcomm).
Realistically, most smartphones are made by the same ODMs. Since they don't make their own screens, shells, CPUs or modems, the only thing being set apart is the software.
I'm not selecting which phone I buy on whether the stock OS comes with lockscreen shortcuts. At best, a software requirement someone might use as a deciding factor is OS support and bootloader unlock. The real differences are in hardware: size, battery life, chipset speed, RAM or other local model enablers, picture quality (this part also depends on good software to be fair), included accessories, satellite connectivity hardware, headphone jack, gimmicks like UWB or FM radio support, whether it's a flip/fold phone, storage space / sdcard support... all hardware differences
If only this were true. Samsung makes arguably the best hardware, but I refuse to buy a phone with Facebook pre-loaded and unremovable, a second (worse) app store preloaded and unremovable, and a bunch of redundant samsung-branded copies of the google apps. The best android images are as close to vanilla AOSP android as possible -- this used to mean Sony or Google branded phones, except Sony doesn't really market phones in the United States anymore and the Pixel phones are diverging from AOSP
The good news though is that by replacing the Pixel's stock OS by Graphene, you get something close to AOSP and arguably better. The hardware is nothing to write home about, but the phones are well priced and the bootloaders are unlockable.
I'm writing this from a Samsung. Their store software hasn't ever gotten in the way and I like most of the UI changes they made besides the extra apps that you can mostly hide or remove (in my case especially because root, but alas I'd not encourage anyone to buy Samsung anymore without the option to control the hardware as if you own it)
Not to defend Samsung specifically, just that most phones' software is fine after a bit of setup whereas you can't download more RAM (don't believe the scams that are out there! :P). Even on Huawei I remember there were some things better than on stock but forgot what specifically (the only thing that comes to mind was a lockscreen menu that you could open with a gesture and I used all the time)
Apropos Sony, that was the only brand where I kept having issues because my mom, who had the phone, constantly had questions about what to do with some notification that the OS was pushing and we couldn't get rid of. Basically product ads, iirc to try this-or-that app or function
I do get what you mean about bloatware, just that it's more of a tie-breaker (saving you an hour of debloating, assuming you stay on stock) as compared to the permanent differences in hardware capabilities
Pixel itself is very mediocre hardware, it's not hard to surpass. The battery is my main problem with it, my current pixel can't barely survive half a day of usage.
Anyone want to place bets in whether this will be an unlockable bootloader, or some GrapheneOS only install path?
Sure would be nice to have phones that can be rooted, or OS replaced. I've been hopeful this would perhaps enable that, but I fret my excitement may be premature.
Providing an unlockable bootloader with all of the security features intact for alternate operating systems is part of our hardware requirements. Our main requirements are listed at https://grapheneos.org/faq#future-devices which covers both updates and hardware security features.
If google allows that for pixels, I don't see why Motorola wouldn't.
Besides, GrapheneOS would probably don't want to get into a situation where their keys are burnt into hardware non-modifiable. They had to revoke such a key once in order to protect their users (against an attempt to hijack the project).
Providing an unlockable bootloader with all of the security features intact for alternate operating systems is part of our hardware requirements. Our main requirements are listed at https://grapheneos.org/faq#future-devices which covers both updates and hardware security features.
I wonder how Google will react if more and more mobile phones with GrapheneOS appear on the market. I suspect they will block further adoption by throwing up all kinds of hurdles.
They could make more parts of Android closed source, even critical ones without which you cannot realistically build an Android phone. It could, however, trigger anti-trust lawsuits, but my guess is they're willing to risk that. I mean, worst-case they only have to rollback to what they already had and maybe pay a fine.
Honest question, because I'm not part of that scene (yet) at all:
I seem to remember that I have read mentions of GrapheneOS for years now, but does this news mean it has been practically vaporware the whole time? Google making Android a walled garden just as bad as iOS shows how important projects like this and its siblings are. I'm impatiently waiting for more Jolla phones to become available, but something like GrapheneOS might be a viable alternative.
One approach is to use one phone (A) for banking and other commercial transactions and use another phone (B) for everything else, e.g., personal communication with friends, family, etc.
Phone A can run corporate mobile OS
Phone B can run alternative OS
Arguably, the data collection, surveillance and advertising exposure when using phone A is tolerable if that phone is only used for banking and commerce
The problem arises when someone tries to use a single phone for every general computing purpose
If that phone is running a corporate mobile OS, then that may expose the owner to an excessive amount of data collection, surveillance and, potentially, ads
Pixels are the only devices providing the updates and hardware-based security features required by GrapheneOS. Motorola and Qualcomm are improving their hardware so future devices will all of our requirements. Motorola will provide us what we need to provide proper updates and is helping us port to their devices. We'll have their support to keep it working well. GrapheneOS needs a lot of hardware related work for our security features.
Our hardware requirements are listed here, but our features also need to be ported to the hardware such as getting hardware memory tagging working for the whole kernel and userspace:
I would love to have more vendor supporting GrapheneOS. I doubt that it will happen though as vendors would prefer to have control over the experience.
Let me know when you're trying to eliminate having a Google or Apple account to do anything instead of making it less intolerable/invasive to have one.
GrapheneOS works well without a Google account and has no built-in way to use one. Most apps work fine without one, but there's the standard issue of services requiring it for login. Having at least a throwaway account is also useful for the sandboxed Google Play Store but people also install those apps via Aurora Store which uses shared throwaway accounts.
GrapheneOS currently has around half a million users but the userbase is rapidly growing. The pace of growth will increase once Motorola flagships officially support it. It will increase far faster once lower end Motorola devices meet our requirements for updates and security features so we can expand to those too. Becoming an increasingly mainstream OS is the best way to address the narrative that using it is suspicious, but that's already nearly entirely fearmongering.
On Pixels, GrapheneOS isn't the stock OS and therefore the devices show a notice each boot with the fingerprint of the non-stock verified boot key. This is a standard security feature on the hardware and something we require to be implemented. Verified boot itself is extremely useful for protecting against both physical attacks such as data extraction and also persistence for remote attacks. The verified boot notice provides a way to verify GrapheneOS is genuine without trusting the computer used to install it. The verified boot key is stored in the secure element along with the OS version for downgrade protection. It's enforced automatically so it's not as if people need to manually check the fingerprint each boot, but it does have value in protecting against tampering despite this. It's a feature we want to have on our own hardware too, although GrapheneOS can eventually be considered the stock OS without the verified boot notice.
GrapheneOS is also clearly installed on the SSD. Every block of the data partition is encrypted on storage but the firmware and OS images are public knowledge and verified through verified boot rather than being encrypted. Putting another boot stage before the OS in order to encrypt the publicly available OS images wouldn't achieve anything since that would identify it as being GrapheneOS itself. The only way to hide the OS would be if the hardware itself had a firmware-based passphrase prompt and the first boot stage of the installed OS was encrypted along with the verified boot key in the secure element being wiped when unlocking. It would be possible to provide, but that would be specialized hardware and therefore it could be identified based on the hardware instead of the software.
The stock Pixel OS isn't designed to be able to be installed alongside other operating systems. It assumes it's the only OS and handles updating both the firmware and itself via the A/B slots. It would be entirely possible to have a main OS in those A/B slots responsible for updating the SoC firmware and acting as a bootloader for other operating systems. That would clearly be there on the SSD if that's looked at and would show the verified boot notice every boot.
Iirc they said they will be able to release Android updates like Android 17, for example, at the time it's released. This year it was a few weeks until it came to stable.
This somewhat indicates to me it will be available when the Motorolas release which should be on their regular release patterns. That's been May for the 2025 and 2026 Razrs.
It will likely be able to support the 2027 variant of the Razr Ultra. It may be another year before we can support the devices a step down from the flagships. It mainly depends on when the lower end Qualcomm SoC adds the security features we need, if Motorola switches to Qualcomm from MediaTek for more of the non-flagship devices and when Motorola can commit to providing longer updates for those. We're likely only going to support Snapdragon Motorola devices for the time being but it could expand further in the future when another SoC platform has what we need too.
This is good news but not so much good news for us poors. I was waiting four this announcement in hopes of getting away from google totally but with the 2026 Moto Signature going for $1000 I am sure the 2027 will be more so I will probably get Pixel 10 instead.
Maybe this will lighten the price on the Pixel 10's though...
Motorola's flagships are going to be their first devices providing the updates and hardware-based security features required by GrapheneOS. It will come to lower end devices but it will take longer.
Snapdragon 8 Elite Gen 5 is the first Qualcomm SoC with hardware memory tagging (MTE). MTE isn't even available on the slightly lower end Snapdragon 8 Gen 5. A lot of the SoC security features are segmented based on price and only the flagship SoC platform has everything we need. Snapdragon's upcoming next generation SoC is the first truly providing everything we need. There's still a lot of work to do since providing the features on paper is different from having those fully integrated to match what we have on Pixels.
If this is successful, I can see this trickling down to the lower end phones in the following years. If for no other reason than keeping their hardware as similar as possible.
All other phones will have a higher price tag due to memory hogging by datacenters. How much will that google pixel 10 be when the motorolla phone arrives?
How does the GrapheneOS threat model account for baseband or firmware-level supply chain risks on Lenovo/Motorola hardware, given their historical consumer security incidents like Superfish? Is the open-source attestation sufficient to mitigate hardware-level tampering?
Now if only there will be a normal sized phone (the old "normal") from Moto with such OEM endorsed kind of support of Graphene then I might as well let go of my fruit no. 17. Yes, I will.
Security-through-obscurity (i.e. using a custom ROM on a lesser-known device) does have some upsides, since you're less likely to be compatible with off-the-shelf exploits. But this is much less true now that LLMs exist, and anyone who can afford the tokens can port any exploit to any and all vulnerable devices.
Who maintains the kernel+driver trees used by the LineageOS port you're using? And what's the modem's security like?
I can tell you from first-hand experience that it is true already (Well, it's true for the specific exploit/device pairings I've tried, I've not tried to construct an omni-exploit)
It would be funny if it actually was intentionally selected, but for DES-like instead of Dual EC reasons, and they're just too embarrassed by Dual EC to admit it.
Since we're speculating here, I hope whatever phone you have allows you to lock the bootloader (My oneplus doesn't after installing LineageOS). And certainly NSA has no way of infiltrating AOSP or less hardened chipsets.
For one, GrapheneOS is open source, unlike EncroChat which was a shady proprietary app distributed on shady modified smartphones.
GrapheneOS also doesn't have any custom messengers or other services which could potentially be monitored. It's very easy to check where your phone is sending requests, and if Graphene was secretly MITMing all of your traffic it would be discovered within days.
Since more than a decade that MITM is not a mass event. It is a targeted event for selected users which are scored as having a low chance of discovering anomalous traffic. It first (publicly) started by government authorities sending fake updates to operating systems which then weaken the target machines or straight up RAT them.
>Of course they'll say they couldn't read it if they are after his contacts and network rather than after him.
From what a friend working in a state police cyber crime office says, "Cellebrite can't currently, unless its a Graphene OS user that's far behind on updates"
They also said iOS is equally safe unless you're an update or two behind.
GrapheneOS seems to do better than anything else at preventing AFU exploitation based on the leaks.
iOS will be quite good BFU but on iOS the auto reboot (brings phone to BFU after 72 hours without unlocking) is, well, 72 hours. On GrapheneOS it's 18 by default and can be as low as 10 minutes.
I ran Graphene without a Sim card for 2 months and as soon as I added a Sim card (with of course, difficult to vet networking) the phone is always hot and the battery life reduced by half. Might be a coincidence but also made me rethink how I feel about Graphene
> I ran Graphene without a Sim card for 2 months and as soon as I added a Sim card (with of course, difficult to vet networking) the phone is always hot and the battery life reduced by half. Might be a coincidence but also made me rethink how I feel about Graphene
Strange you're being flagged since it's easy to find many other people on the graphene forums reporting the same (unresolved) problem.
Doesn't mean it's guaranteed to be limited to graphene in scope, but definitely seems to be a prevalent issue for some yet-to-be-determined reason.
Possibly related, does anybody know if graphene is vulnerable to Pegasus?
It can also indicate you forgot to block the Phone permission etc on Google Play Services.
The easy explanation is that GrapheneOS users are obviously very interesting to Google and so they’ll slurp everything they possibly can, as often as they can.
I disable all Play packages in between installing the rare app on my (often elderly) users’ Graphene devices.
What Pixel do you have? Modem quality varies and signal strength could play a role. My 9a gets hot in areas with poor reception but is fine at work where I get over a gigabit down.
How many apps have network permission? Did you install anything from the play store at all? As a rule of thumb, the play store and everything on it is spyware.
I had the opposite experience. I was pleasantly surprised by the battery life you can get when your phone isn't full of shitware apps and even when you do install shitware, the OS helps you confine it.
That happened to my pixel running stock android and it was the 5G. As soon as I disabled it the battery lasted longer and the phone was way cooler.
After all, I'm totally fine with LTE speeds
Specific devices:
>At the time of writing, within ~12 months, in 2027, the 2027 Signature, Razr fold, and Razr flip will meet the hardware security requirements and should have official GrapheneOS support. Motorola is currently porting GrapheneOS to their devices.
https://news.ycombinator.com/item?id=49038982
I knew it would be their higher end devices but I really wish they would have put it on their lower end as well.
I have a Moto G running LineageOS and it's my favorite phone ever. The ability to have my 800GB of music synced to a sdcard is something I'm loath to give up.
Motorola's flagships are going to be their first devices providing the updates and hardware-based security features required by GrapheneOS. It will come to lower end devices but it will take longer.
Snapdragon 8 Elite Gen 5 is the first Qualcomm SoC with hardware memory tagging (MTE). MTE isn't even available on the slightly lower end Snapdragon 8 Gen 5. A lot of the SoC security features are segmented based on price and only the flagship SoC platform has everything we need. Snapdragon's upcoming next generation SoC is the first truly providing everything we need. There's still a lot of work to do since providing the features on paper is different from having those fully integrated to match what we have on Pixels.
Replying to you here in hopes you see this question.
I'm one of those people who is affected by PWM on OLED screens. I tried a Pixel 9 Pro XL and it didn't work for me. Have a Razr 2024 which mostly works and that's thanks to some custom PWM settings from Motorola.
Will Graphene OS have these custom PWM mitigation settings on 2027 Motorolas?
If anyone runs across this comment in the future, the answer is: YES. On Mastodon, they told me they will have full support for Motorola's custom PWM settings.
I had Motorola Moto Gs all from the first generation to the fifth or sixth, cheap and worked great, had everything one could wish for in a daily smartphone. But eventually they too started growing in size, and so I got an iPhone 12 Mini instead, that I still use to this day. I'm currently hoping I'll find something released in 2025+ that is the same size as the Mini or the old Moto Gs, but they are nowhere to be found...
I think I'll buy one of those new Motorolas with GrapheneOS just to hopefully vote with my wallet a bit, and make them port it/use it for more phones in the future, which just maybe might eventually be a "normal" sized phone again.
We want to support cheaper devices too but flagships will be the first ones meeting all of our update and security features requirements. Providing hardware memory tagging (MTE) and a good enough secure element with the modern AOSP APIs are the main requirements for hardware security features.
Snapdragon 8 Elite Gen 5 is the only current Snapdragon SoC with hardware memory tagging since even the slightly lower end Snapdragon 8 Gen 5 didn't provide it due to being developed a bit earlier despite being launched later. They tried to provide it for both but didn't get it fully working in time. The next generation makes major secure element improvements. We potentially could have supported a Snapdragon 8 Elite Gen 5 with a secure element from another company but there wasn't enough time and the next generation is a lot better in multiple ways. There's still a large amount of porting and integration work remaining to do.
Pretty much the same story. I am hoping my iPhone 12 lasts until I retire and I won't need to carry a smartphone anymore.
Lower end devices simply don't have the hardware required.
We need the devices to meet our requirements so that's the main limitation. The current generation Snapdragon 8 Elite Gen 5 is the only one providing hardware memory tagging (MTE). Even the slightly lower end Snapdragon 8 Gen 5 doesn't support MTE. The next generation flagship SoC has improvements needed to meet our requirements. There's still going to be a lot of porting and integration work. We'll be the first ones using MTE for the whole kernel and OS as we are on Pixels so there's going to be a lot to deal with for it. For Pixels, Google did do testing for MTE across the OS internally but even on Pixels it isn't perfectly supported and we have to fix a lot of memory corruption bugs it finds in both the kernel and userspace.
I would bet that what Motorola can change without trouble on the lower end is more restricted, too. Generally low end models use more parts that are old, off the shelf, and/or shared with several other models to keep costs low, and so major changes can quickly balloon costs.
From the linked url
> Lower end devices will take more time to meet our requirements since the updates and security features aren't as good. It's mostly due to how Qualcomm handles it. The latest Snapdragon flagships have the best security features. We'll also need Motorola to start paying them for longer updates below flagships
GP is likely right still, the longer updates is an also according to the post.
What is your music workflow?
I got stuck in Spotify for new music but that obviously doesn’t work long term
Bandcamp or buying CDs and ripping them, it doesn't take that long and each CD is a fire-and-forget task.
I'm using syncthing to avoid the chore of having to copy them into my SD card
I really wish more artists would put their music on band camp. I have even noticed that some artists who used to put their albums up there no longer are. It's a real shame
For discovering new music, I listen to my old college radio station. About once a month they play something good that makes me do a deep dive. I use Pianobar while I work, and creating a station based on a new (to me) artist tends to give me more to explore. I also use music-map.com from time to time.
As for acquiring music, I use Bandcamp. If they aren't on there, I'm not above finding it via file sharing.
I have a bunch of python scripts that help me rename all my files once I get their tags sorted out. For that I mostly use AudioRanger because it's so simple and I only process one album at a time.
From there, I use Syncthing. But I'm thinking about replacing it with rsync and just kick it off manually when I want to update everything about once a month.
Not him but I can as well throw in my setup.
For playback, I mainly use Navidrome.
For autotagging and importing (moving files), Beets.
For tagging edge cases, MusicBrainz Picard as the GUI and the Python tagging lib underneath it (mutagen iirc) with an LLM inside the pi cli agent for automation.
For format conversion and copying to portable devices, ffmpeg in custom bash scripts managed by an LLM.
This!
Expandable storage is priceless to me and the main reason I opt for this product.
[flagged]
The 2026 Signature doesn't appear to be for sale in the US. Does this mean we have to wait for the lower end devices if we don't want a fold/flip?
Wow, I do not think any of these phones are available in the U.S.
The Flip and Fold are. I see them available on the Motorola US store page.
What I hope is that a compact and high-end device will have Graphene support.
We should be able to support the next generation of the Razr Ultra. It will take longer for the lower end devices to meet our requirements for updates and hardware-based security features.
GrapheneOS on a flip is my dream. I tried with the ZFlips a couple of times but Samsung's kitchen-sink approach is just not for me.
We should be able to support the next generation of the Razr Ultra. It will take longer for the lower end devices to meet our requirements for updates and hardware-based security features.
We think folding devices are a lot more useful and likely to get more users but we already have those via Pixels so flip devices are compelling as a new form factor. We're also interested in having support for new tablets.
New tablet support is very compelling! The Pixel tablet hardware is... passable... but Graphene on something more refined would be amazing! Especially something with a keyboard cover available (no idea if Motorola does this).
How is the crease on the flip? On some of the foldables like the samsung's, the crease is pretty noticeable and for me it bothers my OCD a little bit. I love the idea of a foldable though
I've got one of the Samsung flips and had thought it'd bother me as well, but it's not very noticeable unless you're dragging your finger across the screen, and I've eventually stopped noticing it at all, and notice screen smudges much more readily. Earlier flips were worse with that though. Unfortunately I haven't played with the Razr so don't know it compares. Definitely play around with one in person at Costco/Best Buy/Target/Walmart/wherever before committing though.
I hope flipping devices sell well enough to continue being released because I think they are the best solution for the small phone people.
I've never really tried a flip but it does sound cool.
I really hope this device doesnt have the razr branding
If you mean the logo when restarting? Here's some info about that: https://news.ycombinator.com/item?id=49364610, https://discuss.grapheneos.org/d/4335-remove-your-phone-is-l...
It will be highly unlikely that they modify the hardware exterior look for GrapheneOS.
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.
* 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.
We have waydroid for that.
> 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.
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:
https://privsec.dev/posts/android/banking-applications-compa...
If your bank requires you to use a device that is pre-compromised by Apple or Google, get a different bank.
[flagged]
Most European banking apps work on GrapheneOS. Many support tap-to-pay on GrapheneOS which is unique to Europe. Curve Pay is a financial service supporting tap-to-pay on GrapheneOS in the European Economic Area and UK. PayPal has tap-to-pay and permits using it with GrapheneOS but it's only available in parts of Europe. It's the rest of the world where tap-to-pay on GrapheneOS is an unsolved problem but that can and will improve.
This is false, https://news.ycombinator.com/item?id=49363246
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.
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.
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.
This type of post is why I come to hackernews. Up until now I've been depressed that we don't have a proper "Linux" phone os, but your explanation has properly laid bare the reason why that's a bad idea.
You've given me hope for the future!
The claim I responded to was:
1. Android has existing apps.
2. A subset of existing apps will refuse to run on various shades of non-stock/unofficial system.
I pointed out that 1. the existing apps largely do 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.
If I cut down your page of text to the relevant points, I believe it amounts to:
1. GOS has better app compatibility than waydroid.
2. GOS is supported by some apps that would refuse other non-stock systems.
3. GOS is more secure/private. (This is unrelated and should at most have been a reply to the root comment.)
On 1. compatibility, yes you're probably ahead, though I have to question how much since waydroid is also 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?).
> 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.
What other secure options are those?
> Android has existing apps.
Android has a massive app ecosystem including the largest open source mobile app ecosystem. Those apps are nearly entirely available for GrapheneOS. Very few apps are unavailable for GrapheneOS. It's nearly entirely banking and government apps, but as we said 90% of those work on GrapheneOS.
AOSP and GrapheneOS have hardware-based virtualization usable to run desktop Linux software. It even provides opt-in GPU acceleration with gfxstream and will likely have native GPU virtualization support similar to NVIDIA's paid vGPU in the near future. AOSP and GrapheneOS have a very usable desktop mode which will be getting much better. Android is replacing ChromeOS and was already heavily improved for desktop use as part of being included within ChromeOS. We have that app ecosystem available too.
> the existing apps largely do run on other Linux systems via waydroid
A large portion of Android apps do not work via Waydroid. It has drastically lower compatibility than GrapheneOS and there are fundamental issues with how it approaches it.
The approach they take also severely harms privacy and security through throwing away most of the privacy and security model used by Android. That would not be the case for running AOSP in a hardware accelerated virtual machine, which is what we would recommend doing. It would still have greatly reduced compatibility due to apps using hardware APIs such as the hardware keystores and many apps actively trying to stop themselves being run in a virtual machine or other weird environment. It would work a lot better than using namespaces but would require modern hardware with virtualization acceleration.
> apps refusing to run on non-stock systems are likely to refuse GOS as well
A very tiny subset of overall Android apps entirely ban using a non-Google-certified OS. Most only have checks for the security model being intact and anti-tampering code interfering with running the apps in an atypical environment. We run into these issues with our privacy and security hardening features so we've done a lot of work to maintain compatibility.
> GOS is supported by some apps that would refuse other non-stock systems.
GrapheneOS exceeds all of the security and attestation expectations of these apps. They have no reason to ban using it and we make sure to avoid that being the case. It's only a tiny number of apps banning using GrapheneOS in the first place and a growing number of those are beginning to permit it since they don't actually have a reason to ban it. They do have a reason to ban an OS not providing the security model and attestation functionality they want. We disagree with attestation being used this way, but they can do that while supporting GrapheneOS and a growing number of these apps are doing so.
> yes you're probably ahead
GrapheneOS provides drastically better compatibility.
> waydroid is also 90% AOSP
It's a fork of outdated LineageOS with a compatibility layer to make it run as part of a non-AOSP host OS. It has SELinux disabled which means the app sandbox and other protections aren't intact along with many other major differences. Apps can see these differences and many apps ban it because they can see the security model isn't intact or detect what's happening as a form of tampering.
In practice, GrapheneOS only gets banned by services enforcing the Play Integrity API device or strong integrity level without permitting GrapheneOS via hardware attestation. A growing number of apps are permitting it since they don't have any real reason to ban it. It's easy for them to stop endless negative reviews and customer support complaints from GrapheneOS users by simply implementing Android hardware attestation with Google's open source library for it and permitting GrapheneOS. They can also simply delete the code banning using non-Google-certified operating systems which is what we'd prefer over them hard-wiring permitting GrapheneOS and specific other alternatives.
> yes GOS has gotten some buy-in, but if 90% is good enough
That was only about banking apps. Over 99.99% of overall Android apps work on GrapheneOS. The vast majority of apps are not banking or government apps.
> compatibility as your advantage
It has an immense compatibility advantage along with far better privacy, security, usability and battery life.
> 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
Most users have 100% compatibility since most people don't use the around 10% of banks banning GrapheneOS. Our userbase is also growing large enough that apps cannot ban using it without it being a huge hassle for them. They have no actual reason to ban it, so that's why a growing number of apps are removing the ban on using it. They're usually not willing to stop using the Play Integrity API but once this is on their radar due to complaints they often become willing to implement using the Android hardware attestation API to permit GrapheneOS and other alternatives meeting their requirements. It's not a full solution since it won't allow people's self-signed builds or forks of GrapheneOS but it's progress and it enables the apps to easily permit more operating systems in the same way. They can just add more to their list. We would prefer the Play Integrity API being banned by regulators but this is good enough for now.
> since GOS is missing vitally important features compared to other Android ROMs let alone "normal" Linux systems
GrapheneOS has similar functionality to mainstream Android smartphones. We highly prioritize providing missing functionality not available through apps.
GrapheneOS is an operating system, not read-only memory firmware. There's a boot ROM which loads the main boot firmware from the SSD, verifies it and transfers control to it which then does the same with the OS. GrapheneOS is simply a regular OS installed on an SSD. Verified boot protects it from modification but it's not in read-only storage or anything like that. We don't misuse the term ROM to refer to it and prefer if others avoid it too.
> how long has GOS been without full backup functionality now?
GrapheneOS has much better backup support than the stock Pixel OS and most Google Mobile Services Android devices.
GrapheneOS has a built-in encrypted backup system. It backs up the same data as Google's device-to-device transfer for moving between Android devices. Every app targeting Android 12 or later gets backed up since allowBackup="false" was redefined to only disable cloud backups. Every Play Store app has been required to target Android 12 or later since under a year after the release of Android 12. The issue of apps opting out of backups has been in the past for years.
Backing up more of the system settings and other system data is planned and requires gradually expanding what gets converted into a portable format transferable between devices and OS versions.
> What other secure options are those?
It's up to these companies to define their security requirements. GrapheneOS is far more secure than anything permitted by the Play Integrity API device or strong integrity levels. It supports hardware-based attestation and we publish a signed JSON object providing our verified boot key fingerprints for use with it. They can easily use that and permit GrapheneOS. Other operating systems preserving the Android security model can do the same. Once they allow GrapheneOS, it's easy for them to allow more in the same way. It would be nicer if they stopped using the Play Integrity API and left OS security up to users but most of these apps are not open to doing that. A small portion of apps adopting the Play Integrity API didn't understand what it does and are willing to stop.
> We would prefer the Play Integrity API being banned by regulators but this is good enough for now.
Unfortunately, the EU is currently developing their age-verification-app, and it mandates hardware attestation[1], and it seems that their reference implement those requirements using Play Integrity[2].
[1]: https://news.ycombinator.com/item?id=49148128 [2]: https://github.com/eu-digital-identity-wallet/av-doc-technic...
Our growing userbase and Motorola partnership will give us a lot of sway to get apps to allow GrapheneOS. We can't realistically convince banks, governments and other companies to stop requiring attestation. We can realistically convince most apps to allow GrapheneOS via hardware attestation since it supports doing it via the standard Android key attestation API. We cannot realistically convince apps to not adopt attestation unless they implemented it without truly wanting what it provides which is unlikely for service-side integration. We've only convinced a couple apps to stop using the Play Integrity API. However, we've convinced a growing number to permit GrapheneOS alongside permitting Google-certified operating systems.
Regulators should force Google to stop further closing up Android and to permit alternate operating systems to pass the Play Integrity API device and strong integrity levels. It should not require certification by Google and complying with their arbitrary requirements based around their business model. There should be another path to obtaining certification without Google's involvement where Google has to respect it and permit those devices and operating systems to pass. Most important is stopping them from closing things down more against the original terms they provided Android and gained market share with it. Next most important is a reasonable path to alternatives passing the Play Integrity API based on security standards which do not block updates while waiting for certification.
We don't think it's realistic to stop apps adopting attestation but people should try regardless. A single country with a large market banning would make a huge difference.
https://grapheneos.org/articles/attestation-compatibility-gu... is our guide for app developers on permitting GrapheneOS via hardware attestation. Other operating systems can publish signed keys in a similar way to enable easily supporting them once this is implemented. An organization certifying operating systems could collect these and sign an overall list. It would also be possible to support a broader hardware ecosystem with alternate roots of trust by providing a signed list of those too. This is not the future we want but it is the future we believe we can obtain through a lot of pressure. We would greatly prefer apps not making an allowlist of operating systems. People should be able to make their own GrapheneOS build and use the same apps.
> https://grapheneos.org/articles/attestation-compatibility-gu... is our guide for app developers on permitting GrapheneOS via hardware attestation.
It's not a very good guide, frankly. It's basically a wall of text without clear instructions on what to do, besides "look at the examples Google gave". And even looking at Google's examples, there are no examples or explanations that tell me how to download the list of allowed signatures, and what should I do with the Json schema.
>> Android has existing apps.
> Android has a massive app ecosystem including the largest open source mobile app ecosystem. Those apps are nearly entirely available for GrapheneOS. Very few apps are unavailable for GrapheneOS. It's nearly entirely banking and government apps, but as we said 90% of those work on GrapheneOS.
> AOSP and GrapheneOS have hardware-based virtualization usable to run desktop Linux software. It even provides opt-in GPU acceleration with gfxstream and will likely have native GPU virtualization support similar to NVIDIA's paid vGPU in the near future. AOSP and GrapheneOS have a very usable desktop mode which will be getting much better. Android is replacing ChromeOS and was already heavily improved for desktop use as part of being included within ChromeOS. We have that app ecosystem available too.
There was really no need to write 2 paragraphs to agree with me.
>> the existing apps largely do run on other Linux systems via waydroid
> A large portion of Android apps do not work via Waydroid. It has drastically lower compatibility than GrapheneOS and there are fundamental issues with how it approaches it.
What is a "large portion"? It's worked fine for me but I suppose if you have hard data that might be meaningful. Could you describe the "fundamental issues"? My impression is that they just run the whole Android userspace in a container, which seems like a reasonable approach.
> The approach they take also severely harms privacy and security through throwing away most of the privacy and security model used by Android. That would not be the case for running AOSP in a hardware accelerated virtual machine, which is what we would recommend doing. It would still have greatly reduced compatibility due to apps using hardware APIs such as the hardware keystores and many apps actively trying to stop themselves being run in a virtual machine or other weird environment. It would work a lot better than using namespaces but would require modern hardware with virtualization acceleration.
Again, I know security/privacy is your talking point, but this isn't actually the argument at hand.
>> apps refusing to run on non-stock systems are likely to refuse GOS as well
> A very tiny subset of overall Android apps entirely ban using a non-Google-certified OS. Most only have checks for the security model being intact and anti-tampering code interfering with running the apps in an atypical environment. We run into these issues with our privacy and security hardening features so we've done a lot of work to maintain compatibility.
So, yes.
>> GOS is supported by some apps that would refuse other non-stock systems.
> GrapheneOS exceeds all of the security and attestation expectations of these apps. They have no reason to ban using it and we make sure to avoid that being the case. It's only a tiny number of apps banning using GrapheneOS in the first place and a growing number of those are beginning to permit it since they don't actually have a reason to ban it. They do have a reason to ban an OS not providing the security model and attestation functionality they want. We disagree with attestation being used this way, but they can do that while supporting GrapheneOS and a growing number of these apps are doing so.
Which is a lot of words to agree that yes, many apps only allow stock and therefor block you just like any other OS.
>> yes you're probably ahead
> GrapheneOS provides drastically better compatibility.
I'd like evidence for "drastically", but again we mostly agree.
>> waydroid is also 90% AOSP
> It's a fork of outdated LineageOS with a compatibility layer to make it run as part of a non-AOSP host OS. It has SELinux disabled which means the app sandbox and other protections aren't intact along with many other major differences. Apps can see these differences and many apps ban it because they can see the security model isn't intact or detect what's happening as a form of tampering.
Right. So it's 90% AOSP. Old AOSP with worse security properties, but for compat purposes that's not important.
> In practice, GrapheneOS only gets banned by services enforcing the Play Integrity API device or strong integrity level without permitting GrapheneOS via hardware attestation. A growing number of apps are permitting it since they don't have any real reason to ban it. It's easy for them to stop endless negative reviews and customer support complaints from GrapheneOS users by simply implementing Android hardware attestation with Google's open source library for it and permitting GrapheneOS. They can also simply delete the code banning using non-Google-certified operating systems which is what we'd prefer over them hard-wiring permitting GrapheneOS and specific other alternatives.
You and I have different impressions of how apps approach attestatoin.
>> yes GOS has gotten some buy-in, but if 90% is good enough
> That was only about banking apps. Over 99.99% of overall Android apps work on GrapheneOS. The vast majority of apps are not banking or government apps.
And most apps work on waydroid. Of course the apps that go out of their way to block non-stock are the pain point.
>> compatibility as your advantage
> It has an immense compatibility advantage along with far better privacy, security, usability and battery life.
(You've carved out 3 words in a way that doesn't make sense alone; this is part of either the previous or next bit)
>> 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
> Most users have 100% compatibility since most people don't use the around 10% of banks banning GrapheneOS. Our userbase is also growing large enough that apps cannot ban using it without it being a huge hassle for them. They have no actual reason to ban it, so that's why a growing number of apps are removing the ban on using it. They're usually not willing to stop using the Play Integrity API but once this is on their radar due to complaints they often become willing to implement using the Android hardware attestation API to permit GrapheneOS and other alternatives meeting their requirements. It's not a full solution since it won't allow people's self-signed builds or forks of GrapheneOS but it's progress and it enables the apps to easily permit more operating systems in the same way. They can just add more to their list. We would prefer the Play Integrity API being banned by regulators but this is good enough for now.
90% of the time, it works 100% of the time. Anyways, you aren't 100% compatible, so my point stands.
>> since GOS is missing vitally important features compared to other Android ROMs let alone "normal" Linux systems
> GrapheneOS has similar functionality to mainstream Android smartphones. We highly prioritize providing missing functionality not available through apps.
I'm not comparing to stock, and you refuse to give apps root access so the shortcomings that they can fix are limited. (Yes, I know your threat model demands that the stupid helpless users can never be allowed to control their device. That's actually defensible if security+privacy is your #1 goal, but it does undermine the features that your OS can provide.)
> GrapheneOS is an operating system, not read-only memory firmware. There's a boot ROM which loads the main boot firmware from the SSD, verifies it and transfers control to it which then does the same with the OS. GrapheneOS is simply a regular OS installed on an SSD. Verified boot protects it from modification but it's not in read-only storage or anything like that. We don't misuse the term ROM to refer to it and prefer if others avoid it too.
I love pedantry as much as the next guy, but ROM has not meant read-only memory in like 20 years.
>> how long has GOS been without full backup functionality now?
> GrapheneOS has much better backup support than the stock Pixel OS and most Google Mobile Services Android devices.
> GrapheneOS has a built-in encrypted backup system. It backs up the same data as Google's device-to-device transfer for moving between Android devices. Every app targeting Android 12 or later gets backed up since allowBackup="false" was redefined to only disable cloud backups. Every Play Store app has been required to target Android 12 or later since under a year after the release of Android 12. The issue of apps opting out of backups has been in the past for years.
> Backing up more of the system settings and other system data is planned and requires gradually expanding what gets converted into a portable format transferable between devices and OS versions.
So, you're trailing, say, Debian, and have done for years, and have at most a plan for someday being able to compete.
>> What other secure options are those?
> It's up to these companies to define their security requirements. GrapheneOS is far more secure than anything permitted by the Play Integrity API device or strong integrity levels. It supports hardware-based attestation and we publish a signed JSON object providing our verified boot key fingerprints for use with it. They can easily use that and permit GrapheneOS. Other operating systems preserving the Android security model can do the same. Once they allow GrapheneOS, it's easy for them to allow more in the same way. It would be nicer if they stopped using the Play Integrity API and left OS security up to users but most of these apps are not open to doing that. A small portion of apps adopting the Play Integrity API didn't understand what it does and are willing to stop.
So when you wrote "GrapheneOS and other secure options", you just meant GOS because nothing else matches your definition of security. Again, I don't exactly mind that, but it's disingenuous to gesture at other options that don't exist.
> What is a "large portion"?
20% of apps from the Play Store not working as opposed to less than 1/10000.
> Could you describe the "fundamental issues"?
Many Android apps use functionality such as the hardware keystore APIs and other hardware APIs.
> My impression is that they just run the whole Android userspace in a container, which seems like a reasonable approach.
Using namespaces in the way they do is not a reasonable approach since they're running it with SELinux disabled which means most of the privacy and security model is disabled. It also isn't set up to run that way and requires very problematic hacks. It also ends up not being possible to run more than one instance of it due to those hacks.
> Again, I know security/privacy is your talking point, but this isn't actually the argument at hand.
It is not a 'talking point' and is very relevant in all cases. You may not care about it but most people reading this thread do.
> So, yes. > > Which is a lot of words to agree that yes, many apps only allow stock and therefor block you just like any other OS.
GrapheneOS has better app compatibility than plenty of Google certified devices. In practice, the only issues are with apps going out of the way to ban other operating systems and GrapheneOS does better than anything else. Apps are increasingly permitting it since it exceeds all their requirements and it's just a little bit of extra work for them to not solely depend on Google's API.
> I'd like evidence for "drastically", but again we mostly agree.
It's easy to check and other people have done so.
> Right. So it's 90% AOSP. Old AOSP with worse security properties, but for compat purposes that's not important.
No, you're wrong. It's very important for compatibility. Apps can and do detect large parts of the security model being disabled. A far larger portion of banking and government apps won't run on it. Having 90% compatibility with those is certainly better with 30% or less.
> You and I have different impressions of how apps approach attestatoin.
You don't have the experience and data we do. We have a large number of users and reports from them. We also have conversations ongoing with numerous banking apps about it and have seen multiple apps permit GrapheneOS. Revolut is currently talking to us, although the app works on GrapheneOS since we worked around how it was being banned in January 2025. We're also talking to Square (Cash App, etc.) and others. It is a problem which can be solved and these companies are largely not against solving it or even actively want to solve it, it just isn't something they've gotten to yet. The GrapheneOS userbase growing has begun to make this problem solve itself.
> And most apps work on waydroid. Of course the apps that go out of their way to block non-stock are the pain point.
No, a large portion of Android apps do not work with it because they use APIs unavailable or broken with it. Many banking and similar apps check that the security model is intact which it clearly isn't so they ban it but they would happily run on a non-stock OS which appears to have it intact.
> You've carved out 3 words in a way that doesn't make sense alone
What we wrote makes sense.
> 90% of the time, it works 100% of the time. Anyways, you aren't 100% compatible, so my point stands.
90% compatibility with banking apps is far better than less than 30%. You're trying to make it seem black and white when it isn't. Google certified Android devices don't truly have 100% app compatibility in the first place. Apps have plenty of required features, minimum Android version requirements, requirements for specific models (some apps only work on Pixels, Samsung flagships, etc.) and a lot more. Some low-end devices have broken support for Camera2 and other APIs despite the CTS. GPU drivers are buggy and games are buggy so there are compatibility issues. Perfect compatibility never exists. Nearly every non-banking app working fine and 90% of the special case of banking apps working fine is very good compatibility.
> I'm not comparing to stock
Most people are using OEM Android forks or iOS.
> and you refuse to give apps root access so the shortcomings that they can fix are limited
A userdebug build of GrapheneOS has root access. It's not suitable for production builds used by the vast majority of users and isn't in those. It's also incredibly niche and not very useful. What you're actually referring to is using a rootkit framework providing app accessible root access where a huge portion of the OS has root access. You're not talking about the user having root but rather a framework for apps built with disregard and even disdain for security being granted root via a dialog which a user cannot truly ever revoke or undo the consequences of granting beyond a reinstall of the whole OS.
> I know your threat model demands that the stupid helpless users can never be allowed to control their device
The app accessible root frameworks you're talking about drastically reduce the privacy and security of the OS for all users including ones never using it to grant root access to an app. Granting root access to apps built with such disregard for following security best practices is also not somehow unproblematic because you think they're trustworthy since they're open source.
> but it does undermine the features that your OS can provide
No, it means we build features with proper implementations following security best practices instead of doing it with half-baked hacks via a massive portion of the OS having full root access and granting that to apps.
> I love pedantry as much as the next guy, but ROM has not meant read-only memory in like 20 years.
It means read-only memory in embedded, information security and in the context of GrapheneOS which is an overlap of both. GrapheneOS works on security including boot security where it's very relevant. When someone says ROM recovery in the context of GrapheneOS, that means the boot ROM recovery mode loaded when firmware on the SSD can't be loaded. It does not mean the OS recovery mode. It's not correct terminology to refer to GrapheneOS. It propagates unnecessary misconceptions and confusion.
> So, you're trailing, say, Debian, and have done for years, and have at most a plan for someday being able to compete.
No, it doesn't provide a similar backup system portable across devices and major OS versions.
> So when you wrote "GrapheneOS and other secure options", you just meant GOS because nothing else matches your definition of security. Again, I don't exactly mind that, but it's disingenuous to gesture at other options that don't exist.
No, our response said the apps should set a security standard and enforce it fairly. They should not enforce Google certification but rather define the standard security expectations and permit anything meeting them. GrapheneOS is much more secure than any Google certified OS, so it would meet actual security standards they set. Whether other alternate operating systems meet those standards depends on what the app developers set as the requirements. Many Google certified operating systems won't meet reasonable security standards and would need to be banned if the enforcement is fair.
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.
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.
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.
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.
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.
This is a meta comment, but I just wanted to thank you for your engagement and insight that you've shared throughout these threads. I personally get a ton of value out of it and really appreciate 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.
Interesting. Could you elaborate? I always thought that Secure Boot is reasonably secure (provided you can set it up in the first place).
The standard UEFI Secure Boot used with traditional Windows and traditional desktop Linux is an incomplete and insecure implementation of secure boot. It doesn't verify the vast majority of the OS, nearly always lacks an unbroken chain of trust from the hardware, does not verify all of the firmware and lacks downgrade protection for both most of the firmware and the OS. In the typical setup, it trusts an enormous number of keys and software. It barely provides any useful security properties.
Secure boot was widely used as a term prior to the UEFI usage of the term including many much more meaningful implementations. The term verified boot refers to the same concept but avoids it being confused with solely verifying a late stage bootloader and OS kernel from UEFI firmware.
Ah yes, so if I understand correctly, you're referring to the fact that, e.g., on Linux a typical Secure Boot setup will verify the kernel (if at all) but not the rootfs. Yes, that's of course a huge issue (as is mutability of the rootfs in the first place). I think what I had in mind is indeed more akin to the "verified boot" setup you described.
There are other reasons for porting, like control over your own device.
[flagged]
I haven't tried using Wade Droid on a phone, but on a fedora desktop it is a little bit rough. It takes a lot of finagling to get anything that requires Google services running, and that is a surprisingly huge amount of apps that people want
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.
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.
"Most" seems quite inaccurate. There is a Graphene OS banking app compatibility database [here](https://github.com/PrivSec-dev/banking-apps-compat-report); it is not easy to filter for European banks, but the [incompatible](https://github.com/PrivSec-dev/banking-apps-compat-report/is...) ones are less than 10% of the total [reports](https://github.com/PrivSec-dev/banking-apps-compat-report/is...).
There are quite a few people from Europe on HN saying that you can find banks not forcing the duopoly apps on you, in different countries.
You can. Thats why I said most.
However at that point you'll likely pay for the privilege.
Yes, fighting for your rights is not easy.
It was literally capital one.
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?
Good for you. Nobody is challenging what a web app can or cannot do. I love PWAs but services I need every day either don't have a web interface at all, have limited features or are unusable on a small screen let alone having a PWA. This is not about technical abilities but about what companies actually do.
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.
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.
The majority of the world don’t do this anymore.
This is true but the problem is every now and again some of us have to deposit a cheque because even if we would love for cheques to go the way of the Canadian penny they are very much still a thing
FWIW in the USA, ally.com lets you upload jpegs from a desktop browser for all your 70s banking needs.
No you cannot, as of yesterday. The mobile app doesn't even allow your choice of camera app, to avoid even the tiny amount of fraud that doing so might enable.
Looking down the thread I am also thinking maybe this is a Europe thing? I am usa.
https://news.ycombinator.com/item?id=49363246
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.
Yep. Everyone here is talking about "just use the website" but ANZ Plus, a "neo-bank" which is increasingly popular here in Australia, literally has no web portal.
Its app is really nice and native, though. That, along with a decent interest rate, is why I use it.
>deposit a cheque
That would be inconvenient if this was 1985.
> What's stopping me from using a browser to log in to my bank?
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), https://seg.bb.com.br/home.html is the diagnostic page for that "security module" (the FAQ page there has links to the installers).
Some banks are app only and/or build MFA functionality into their apps.
That would be a hell naw from me.
You know the web is also bits and bytes right? Someone who has a say should fix it so banks can do whatever they need right in the browser.
I am not a bank so my being aware of things is not going to change much.
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!
The relevant regulations are Commission Delegated Regulation (EU) 2018/389 and the earlier Directive (EU) 2015/2366.
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).
That, in and of itself, wouldn't be a problem. The way most banks implement it, however, is by giving you two choices:
1. You use their mobile app (which likely requires device attestation and Google Play Services, so won't work on a plain LineageOS install)
2. You use their CardTAN device, which is extremely inconvenient to always carry around.
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.)
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.
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".
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.
Where I live, the overlap between banks with physical branches and those that don’t require an app or cardTAN is nonexistent - genuinely zero. But maybe I’m just old-school for wanting to have the option to visit a branch.
And what do people without a smartphone use?
A hardware-based CardTAN device, which is super inconvenient. Or else they can't do any online banking at all.
crying in EU :(
Name five.
BAC in Central Americal https://www.baccredomatic.com
If you bank with them: have you contacted them?
This is a social issue - not a technical one.
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.
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.
Sounds like it's time for a new bank.
The bank website typically needs the app to enable two factor authentication in a lot of places.
For eg. There's no browser based alternative to make UPI payments that i know of.
How about for clients with no smartphones?
You're basically out of luck. This is happening all over the world these days with various government services.
It's not just for clients with no smart phones. It's also clients who activate developer mode on their smartphone etc... clients who use VPN. Clients who run AdBlocker. Clients who use Firefox.
There needs to be a severe push back against this.
Things have gotten so crazy that the homeless here are walking around with QR codes printed out when begging for money. I'm guessing they're a network of people who share the same smartphone/payment method..
I am so grateful for the large religious population in my country who eschew the smartphone. I suppose because of them every back and government service is available to all citizens.
They're 50/50 to either make it work or fire you as a customer - you may as well try.
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
Maybe that is possible in Germany. It is impossible here in Sweden.
Or in other words: of course you can have mobile bankid without a smartphone, just use a tablet computer ;)
@fsflover: and my mobile phone provider. And my insurance. And my eletricity provider. And my housing associations customer portal. Getting doctors appointments. Mortgage. Union. National retirement savings account. Some of these may have some alternative left, but far too many you will be left out.
Well, I can buy a train ticket without it, so I could still leave.
Do you mean to say that all these services require strong device integrity to function in Sweden?? In Australia, no local app that I'm aware of (banking, finance, government, medical) requires any form of device integrity - otherwise I couldn't use them. The only exception I've encountered is Google Wallet.
I wonder why there would be such a difference in policy between countries, not only in government but across the private sector? This doesn't make any sense to me. If anything, I'd expect Sweden to have a more sensible, left wing attitude than Oz.
The comment that I was replying to was suggesting (to me) to live in sweden without mobile bankid (centralized 'banking' 2FA app on smartphone). I have here listed services that require said mobile bankid. Mobile bankid works for me and others on graphene os, but would likely not work on an arbitrary linux smartphone.
Thanks for the explanation, it is more clear now. Some people manage to live without bankid it seems, but it's painful, https://news.ycombinator.com/item?id=48339503
[flagged]
Highly location dependent. This is more true in Europe than in America.
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.
my bank (and others) doesn't require the 2f to be a smartphone
Well, it's kinda hard to scan a QR code displayed on your screen when the camera is attached to its back (semi-joking)
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.
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.
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.
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).
Anyone getting BMW digital keys to work on Graphine OS?
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.
Almost none support strong dedicated HW authenticators or second factors. Not even as an option to those who care.
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.
A lot of it is security theater plus lazy (as in "doing the minimum amount of work possible") compliance with regulations
But they care a ton about security theater. Advanced device integrity? That sounds secure to me!
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.
I can't care less about "apps". Web is already powerful enough to do all sort of stuff on device.
That said, I think wasi containers support for a mobile OS would be a game changer.
(^ 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.
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.
There are things that you just can't do with wasm. wasi was designed to fill the gap. If you can remember, wasi was all the craze right before AI came out and suddenly it just faded in the background.
> Graphene lets you run them.
It seems not all of them, and that things will only get worse if recent news comes true.
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".
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.
I'm guessing the companies will continue to be difficult, but it'll be amusing to watch, at least.
I highly doubt companies who did that reasoned out of supporting GOS, so I'd be surprised of they reason back in.
Yep. Had to change banks because of my old one suddenly dropping grapheme support by adding stupid attestation mechanics.
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.
same here... unfortunately, there are too few users of alternative Android distros for the banks to care...at all
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.
It's not invasive generally speaking. My healthcare provider allows me to access e-perscriptions via the app. But for that there are certain security requirements which this particular Healthcare provider equated to "Android good, GOS bad"
> My healthcare provider allows me to access e-perscriptions via the app.
Why can't the prescription be sent to email or collected on a website? I don't see why an "app," especially one signed by Google is necessary for something like this. It wouldn't surprise me if the app requested location or sensor access in order to provide a "personalized experience."
90% of those apps do work on GrapheneOS. A growing number are adopting the Play Integrity API but a growing number with it already implemented are choosing to also permit GrapheneOS.
[flagged]
[flagged]
90% of banking apps work on GrapheneOS.
https://privsec.dev/posts/android/banking-applications-compa...
Stop parroting this. It’s not true.
Diminishingly few apps do not work, and it’s down to them.
[flagged]
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.
[flagged]
Traditional desktop Linux heavily involves big tech companies including IBM (Red Hat). AOSP has a massive amount of non-Google companies and individuals working on operating systems based on it. It would survive without Google.
You're misinformed about security preview patches. It has nothing to do with Google being hostile. Additionally, our security preview releases have regularly included patches for components not specific to Android such as wpa_supplicant prior to those being publicly disclosed by the upstream projects.
> Traditional desktop Linux heavily involves big tech companies including IBM (Red Hat).
Yes, for some definition of "heavyly" that you chose. Yet no single megacorp can decide single-handedly on the future of Linux or do this: https://news.ycombinator.com/item?id=49364745
> AOSP has a massive amount of non-Google companies and individuals working on operating systems based on it.
Can you define "massive" in, e.g., percentage of lines of code? This looks unsubstantiated to me.
The parent has a good point and shouldn't be flagged.
> AOSP has a massive amount of non-Google companies and individuals working on operating systems based on it.
based on is the important part here. Yes, AOSP would survive without Google. But as long as Google is in control of AOSP, it controls the direction in which AOSP and all downstream projects are headed. Because of breaking changes in AOSP, there is a cost in maintaining downstream changes. So downstream projects cannot veer off too far, short of a hard fork.
> You're misinformed about security preview patches. It has nothing to do with Google being hostile.
Does it not? From the 2025092500 GrapheneOS release notes: "We strongly disagree with broadly distributing patches to OEMs 3-4 months before the official publication date. It further delays getting patches to users and sophisticated attackers will have no issue getting the patches from one of many people at Android OEMs with early access."
Sounds pretty hostile to me.
I believe the timely security patch issue will be resolved with the Motorola phones due to the OEM partnership.
Long term in the future, surely the open source community forks AOSP itself and maintains it. The worst option would be giving up and trying to focus on Linux (desktop) imo.
Because Android is miles ahead in terms of security, permission management, app separation, power management, privacy...
Linux crowd can not even agree on compositor, and if systemd or sudo is a good idea.
> Linux crowd can not even agree on compositor, and if systemd or sudo is a good idea.
This is actually a feature.
Why should Linux users have to agree? run what you want, it's your computer.
Well, if you want a mass market device that runs Linux, you have to meet the market. Otherwise we can start tracking 2525 as the year of Linux on the smartphone. If man is still alive.
The concept of a mass market device is sort of incompatible with the freedoms we generally associate with linux -- Android is really the closest thing we can hope for. It runs a linux kernel, a very non-standard userspace, and is relatively locked down (when compared to a general purpose linux distribution)
I think "linux smartphone" would end up looking very similar -- some UI on top of a kernel with a very non-LSB userspace; therefore the concept is really not all that compelling
> The concept of a mass market device is sort of incompatible with the freedoms we generally associate with linux
But take that far enough and you get Stallman'd into a corner where someone points out that's great, but no phone for you.
Because there are only a few people who actually build this kind of software and if they cant agree how it should look. No projects will have the dev power to come out with a solution.
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.
You can strongly disagree but it doesn’t change the fact that the comment by the OP is objectively true.
Especially in this political climate it’s insane to recommend people switch to a phone OS that can be pwned via hardware or software means in virtually zero time versus something like GOS + a Pixel or an iPhone.
Can all the Linux servers also be pwned in no time? This is a huge exaggeration. This requires the users to know what they are doing and running -- with this I agree. But it's doable today.
No.
The hardware and software security of Android/iOS/iPadOS/GOS devices are leagues ahead of Linux servers in all aspects and it’s not even close (but they also serve different purposes so to some extent I’m not sure how 1:1 this comparison is). However, this discussion focuses on desktop style Linux distros which is what these phones are running which have inadequate security. Desktop Linux is inferior security-wise to a server environment where each process/app is running as it’s own user etc. Desktop-style Linux phones also have virtually zero hardware security versus the alternatives.
It doesn’t matter if a user knows what they are doing. For example installing so-called “trusted” apps means they’re only trustworthy at that moment in time and not forward-looking. All it takes is one supply chain or runtime security exploit. Software security is also extremely poor with a lack of comprehensive sandboxing and so on, I would just read the grapheneos accounts replies on here since they’re writing entire novels on this.
I mean even GrapheneOS shows how relevant this is with Samuel Tunick, on the front page today. If he’d had a desktop Linux phone that was seized from him while in AFU, sure it would be “private” but there would be virtually nothing stopping officials from running through his entire phone since so many of these desktop Linux distros rely on poor security elements if any on top of FDE with LUKS so your entire device is basically exposed and unencrypted after the first unlock.
This whole comment was borderline stream of consciousness so I apologize if anything is unclear here.
Because you need app support. Not even Microsoft could pull that off.
You mean Microsoft proactively kept shooting devs in the kneecaps?
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.
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)
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.
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.
Other than that there's waydroid, alien dalvik etc.. that run another Android instance in a container.
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.
> The advantage being, we can manage packages using a regular Linux distro
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.
You can't because a lot of apps check that the phone is controlled by Google with Play Integrity.
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.
It still exists yes but Google tightened the screws to make sure it just keeps to be an hobbist project and not a competitor
Well for me I use Lineage without even MicroG and everything I need works - yes even banking
Same here. Banking works in a browser, don't need GAPPs for any apps I use either.
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.
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 can barely pull off their flagship desktop operating system, so that doesn't say much.
Microsoft could, but abandoned just as they gained traction in Europe
I miss my Windows Phone...
Doesn't windows run android apps natively now?
It doesn't. There was a plan, but Microsoft abandoned it.
They did end up releasing Windows Subsystem for Android via the Windows Insider Program, which was enough for the OSS community to take it over after it was abandoned. It still exists and has worked quite well for my use case: https://github.com/MustardChef/WSABuilds
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).
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.)
AOSP even without the GrapheneOS improvements has drastically better privacy and security than a traditional desktop distribution. A mobile Linux distribution with a much better privacy and security model than traditional desktop Linux is still Linux. A similar approach can also be used on a laptop or desktop too.
We provided a much more detailed reply at https://news.ycombinator.com/item?id=49364220.
Cheers, thanks for all the work you do on the project.
There is still a philosophical reason for supporting a version of Linux for mobile devices that is not dependent on Google, but is community-driven, for users with different priorities.
That is not really relevant to the GOS project though, and the fact that GOS is probably the easiest way to get a Play Services-free mobile device kind of drags it into discussions that it doesn't necessarily belong in.
Again, thanks for your work, and I appreciate your team's focus on your goal of the best security possible.
once Huawei was forbidden from using Android - that's when people ie western markets & the world at large should've shifted. look at HarmonyOS.
in China - there's no google apps available on their 'android' versions.
their platforms are already performant and fluid - so people should build on that.
It's a shame that the newest version of harmonyOS isn't open source.
It seems like such a missed opportunity for China to challenge American dominance overseas.
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?
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.
AOSP even with the GrapheneOS improvements provides far better privacy and security than a desktop distribution. Those are the hardest things for a desktop OS to accomplish since they cannot force the whole software ecosystem to conform and very few developers care about it. Developers largely treat their own code and dependencies as trusted. Few developers are inclined to heavily invest resources in limiting their own access and capabilities. The baseline sandbox provided by AOSP enables the GrapheneOS improvements because of how much is standard.
https://news.ycombinator.com/item?id=49364220
AOSP has way better security and therefore privacy than desktop linux.
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.
Thank you for actively commenting in this thread with detailed responses
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.
>at least for my threat model
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.
https://grapheneos.org/features
[flagged]
> AOSP is only more "secure" because, on some devices like Pixels, it exploits hardware features typically not found on general purpose computers.
You don't think, say, isolating apps has anything to do with it?
Why are we acting like isolating software is impossible on Linux? It isnt even difficult, there are about a dozen different models to choose from.
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).
[flagged]
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.
[flagged]
> That's a rather bold claim.
No, it's not a bold claim. It's a strong consensus among people working on privacy and security engineering or research.
> Care to elaborate?
We did in our response to you at https://news.ycombinator.com/item?id=49366321 and posted more elsewhere. Others have posted far more details about it in articles and papers.
> 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.
It's not impossible, no, but it's not the default, and the different models tend to have various different issues.
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.
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.
Also almost any native desktop app forced to mobile has broken ux.
Your point is valid for every flavor of Android except GrapheneOS.
GrapheneOS’ security model makes that of desktop Linux look like a joke.
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.
It also has many other advantages including the OS and app ecosystem heavily using memory safe languages from the beginning, which has greatly increased over time. The majority of new code added to the OS has been in memory safe languages for years. Android is replacing Java with Kotlin and C++ with Rust but it was always using a lot of Java and moved to using ahead-of-time compilation for it with Android 5. It then moved to a more complex way of compiling it but GrapheneOS has kept using ahead-of-time compilation.
It has much better adoption of modern exploit protections and far better testing with sanitizers for both the kernel and userspace. It enables us to do even better because most of the memory corruption bugs caught by MTE are resolved. We do still need to resolve more, but it would be far more impractical for us to do it on the desktop.
Android uses SELinux for both whole system MAC and MLS policies with deep OS integration. It uses it for a massive amount of kernel attack surface reduction with allowlists for socket protocols, devices, ioctl commands and other functionality. It's far different from the traditional targeted approach used by desktops or even rare use of whole system SELinux for desktops/servers. It's nearly a completely different thing in practice. The OS has it deeply integrated in userspace for enforcement beyond in the kernel and it's developed around it. It's the main basis for the app sandbox and a lot of other isolation in the OS. OS processes are specifically split up and have IPC set up in a way that they can be contained well with it.
The mandatory app sandbox with yearly backwards incompatible privacy and security improvements as part of new target SDK versions is the most important difference. It's the basis for GrapheneOS being able to do much better. Having the infrastructure it already has available means we can add our features such as Contact Scopes, Storage Scopes and our Sensors toggle on top. We plan to add a lot more, but there are also the yearly improvements we get in the baseline such as how Camera, Microphone and Location have supported one-time grants for years, can only be used while apps are in use once granted (with Location have an extra layer of background opt-in) and precise vs. coarse location.
AOSP on a Pixel without the improvements made by GrapheneOS is far more private and secure than desktop Linux. The starting point is far more secure than the hardware, firmware and software of the desktop ecosystem. It has a far better privacy model too. GrapheneOS does heavily improve the permission model, exploit protections and much more but the starting point was already much better.
https://news.ycombinator.com/item?id=49364220
Seems like it's the same problem as chromium. Is it better to get off the Google controlled ecosystem? Yes. Is it easier to leverage the Google controlled ecosystem? Also yes.
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...
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.
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.
[flagged]
I have a Pinephone Pro. It's nowhere near usable as a daily driver.
This is not a good example. Pinephone Pro had a very small developer community (of volunteers) and thus quite undeveloped software. It was discontinued for this reason. Librem 5 and Pinephone are usable as daily drivers, albeit they do require compromises.
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.
Android is a massive operating system family and exists without Google Mobile Services in the OS. It's entirely possible to turn things around in terms of Google gradually taking more control from OEMs and squeezing out competition.
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 every attempted Linux phone gets zero battery life. I'd like to be able to leave the house for more than 3 hours.
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.
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).
Because it's a mobile platform and "GNU+Linux" is laughably terrible in this space.
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.
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).
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.
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.
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.
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.
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.
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.
[flagged]
> I have read your marketing materials
GrapheneOS is a non-profit open source project. We provide documentation and other information on the project.
> Android is not a Linux distro nor is it directly derived from Linux
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.
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.
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.
> Mobile phones are not "personal computers".
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.
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.
> Trying to act like it being "mainstream" or "common" relative to desktop distros matters is just laughable.
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.
> And I take issue with the notion that a monolithic kernel cannot be secure.
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.
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.
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.
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.
> then why arent you guys working on the next kernel for personal and high-performance computing
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.
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.
[flagged]
> In the future, I'd recommend replying on your own account rather than an organization sockpuppet. Thanks!
We're using a project account making it clear these responses are from the GrapheneOS project. That's the opposite of a sockpuppet account. We've moved to using this project account instead of individual accounts because of personal attacks directed towards our team. A community member created this account and transferred it to us to encourage us to keep posting on Hacker News.
[flagged]
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.
> you can't compel someone to support your niche platform
You mean, a browser?
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.
It's almost like the free market only works when we have well-defined and regulated markets. 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!!"
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.
> Don't we have free market capitalism?
Not in the mobile world no, it's not a free market by any means
no, we don't, far from it.
(which doesn't mean there's not a lot farther from here).
> I've never really understood why we chase Android-alikes on mobile platforms instead of trying to build on mainstream Linux.
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.
I mean you invoked "mainstream Linux" and "Nix" in the same paragraph. That alone should clue you into why this, absolutely, does not work.
See here is the problem:
https://wiki.pine64.org/wiki/PinePhone_Software_Releases
"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.
I mean... In that page there is no less then 25 different "Linux Phone OSes" listed.
None of them actually work.
They are all going to be slow, they are all going to burn through battery life. There is no meaningful security to speak of.
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.
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.
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.
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".
And Android can still use nix-pkgs if you really wanted to.
[flagged]
[flagged]
[flagged]
AOSP is Linux.
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.
A year ago or so, the ThinkPhone 23 (Snapdragon 8, 2023, a weird "flagship") was available for 229€ new on various retail stores. The phone also supports Mobian/PostmarketOS and the bootloader is unlockable with no adverse effects.
Out of nowhere, it received (along with other older phones) updates up to Android 16.
I wouldn't be surprised if the "sudden" update was just a side effect of Motorola preparing for Graphene to be released on these older phones.
No current Motorola phones meet their hardware requirements. 2027 flagship models will be the first to be supported.
https://x.com/GrapheneOS/status/2058730195041812839
https://x.com/GrapheneOS/status/2064124713501163912
Oh, that's unfortunate. I thought they meant support would be released in 2027, not that phones from 2027 would be supported only. :(
Not sure about other phones, but ThinkPhone 23 was supposed to get Android 16 anyway
https://www.androidauthority.com/lenovo-thinkphone-hands-on-...
I have a 'long life' Android device (Zebra EM45) that has only recently gotten its Android 15 updates; its committed through Android 16 so I assume it's also waiting on Qualcomm to get its act together and in gear for whatever final patches are required for the QCS5430. IIRC, QCOMM is promising "10 years" on the CPU.
I bought the Moto signature a month ago , I already assumed it prolly won't support graphene, since some of the previous replies on X indicate that the graphene team requires full hardware compliance with their requirements, and the Signature apparently is not compliant yet.
Anyway I ended up buying a really good smartphone.. just not a graphene supported haha :(
Also this is really great collab from moto & graphene as more vendors will officially recognize Graphene as legit OS (legel/OEM is different concept). I heard month ago Volkswagen banned graphene, hopefully we we will see moving things in opposite direction...
They didn't "ban" them, but they did enable some attestation feature that effectively "bans" anything that isn't Google Android.
Which still makes you wonder why Volkswagen is so keen on alienating what little is left of their customer base with completely stupid security theater.
Because the EU is run by lawyers and lawsuits. They probably decided there was a risk of being sued for insufficient security if they didn't enable every security feature, and they considered it as zero impact to customers because nobody uses graphene.
Yes, but that is still very confusing to me, because you're not paying other people money so that they just follow incentives without thinking, vision or backbone.
The whole idea of buying something is giving people money for their (assumed correct) judgement, which then leads to desired artifacts downstream.
No, the idea of buying is that you get something in exchange for money.
Yes, but not any something, but a specific something shaped by taste.
Just a specific something. Taste has little to do with it.
It's fair to say they banned GrapheneOS but they didn't only ban GrapheneOS. It's very rare for apps to specifically ban GrapheneOS but Revolut uses an SDK which tried to do it. We worked around it and Revolut works on GrapheneOS since January 2025 but not for lack of trying to ban it by an SDK they use and it sometimes blocks our users.
[flagged]
> I appreciate the truth more than narratives
It is the truth.
> Volkswagen did not ban you.
They banned GrapheneOS and other non-Google certified operating systems.
> Volkswagen probably don't even know that you exist.
They're aware of the existence of GrapheneOS. They've received immense pushback for banning it. They have customer support templates for responding to GrapheneOS user complaints.
> because like this it's just storytelling
Revolut shipped a check for ro.build.user being set to the string "grapheneos" resulting in using the app being blocked. They also banned the yellow verified boot state at the same time but quite notably did not ban the orange verified boot state. This was our release working around it to get the app working again:
https://grapheneos.org/releases#2025012600
We know what happened and what we had to do to work around it. It's verifiable that this was shipped by Revolut.
> I know of course that uncompromisingly maintaining something that challenges the status quo needs stories to keep the drive alive.
It's you who is pushing a false narrative.
> Idk man I think you people need grounding. That, or I just need to stop seeing the humanity in you, start seeing you as a software vending machine and applaud your (hate to say it, but) delusions, as those lead to you working harder for stuff that is useful to me.
You're not welcome to contact us again after this.
[flagged]
The people at VW don't think about the customer. They are essentially bureaucrats who only live to expand their personal fiefdom in the bureaucracy. I bet that many in the IT-security team would insist that their team doesn't have customers.
> I heard month ago Volkswagen banned graphene, hopefully we we will see moving things in opposite direction...
Why would anyone want a car app? Is being tracked by the car's telematics unit (cellular modem) not enough?
I was hoping for Fairphone support but they said it's not happening.
> Fairphones lack the updates and hardware-based security features expected by GrapheneOS.
https://x.com/GrapheneOS/status/2089937246619128257
I just wonder how they handle full Google's certification for hardware integrity + Google Play Store with GrapheneOS. They contradict on this part on the normal GrapheneOS mod and I don't see a way how they will not on Motorola phones.
Banking apps (e.g. Revolut) block GrapheneOS actively and many other apps too.
But it will be interesting times once they are out!
> Banking apps (e.g. Revolut) block GrapheneOS actively and many other apps too.
You've misunderstood something here. Revolut doesn't "block GrapheneOS actively". I'm running Revolut and most of my banking apps on GrapheneOS right now.
In my experience, there are two major categories of incompatibility:
- High levels of Google Play Integrity checks: app only works on releases of Android that have been allowlisted by Google. The only app that does this for me so far is McDonalds.
- Commercial root detection APIs: some of GrapheneOS' security features like "Secure App Spawning" trip root detection heuristics. This is the kind of incompatibility I usually run into for banking apps. You can disable individual features on a per-app basis these days to get around this.
>Revolut doesn't "block GrapheneOS actively".
It's not happening for everyone but unfortunately:
https://nitter.net/GrapheneOS/status/2085154315799314918#m
That's really unfortunate. Revolut has luckily been working well for me but time will tell...
I am beyond excited about this! Very cool.
When Google acquired motorola, I was excited at the possibilities. When they sold Motorola off, I thought it a deeply unfortunate move.
With this announcement though, I am now seeing it in a very positive light. Given Google's current position, if they still owned Motorola I can't see this sort of collaboration with grapheneos ever happening.
Major kudos to the graphenos team! This is a huge milestone, a huge accomplishment, and a real world validation of the incredible work that you are doing. Thank you so much for everything you have done
[flagged]
There is a little bit of clumsiness in the way Google communicates with the public. What they really mean to say is: we need to be broken up.
I am in awe at the amount of capital Google's market dominance affords them and the consistency with which they squander that capital.
https://killedbygoogle.com/
This is not the way.
Well.
Lest you forget that modern computing exists because ATT built unix and then threw it out to the public, at speed, as they drove away from it as fast as possible. (Something about being an actual monopoly...).
There is at least one thing, on that list that I can almost assure you will be coming back (in concept and spirt) in the next 5 years. Likely open source, because google tossed it...
Meanwhile it has other very public and open winners: Golang, Kubernetes being two stellar examples of them not dropping something like a hot potato.
Yeah, its the "well, legally, we have to provide the source code, but we make it as painful and slow for you as we can without it becoming a blatant violation of the GPL."
Not quite, they could make you request it by post and send it on a stack of floppies.
Sounds like a cheap way to get my hands on some floppies.
you are right a stack of printed qr codes is better
No, that's too easily machine-read. Print it in a fancy calligraphy font or one with ambiguous characters.
Reminds me of Lavabit where the US wanted the encryption keys and they printed them out in a 4 point font :D
https://en.wikipedia.org/wiki/Lavabit#Legacy
That's too convenient, cameras can read many qr codes at a time. Encode the binary on some punch cards.
Pretty sure cameras can be used to read punchcards too.
This sounds like a fun project. Somebody already did it, apparently: https://hackaday.com/2012/07/30/reading-punch-cards-with-an-...
They don't have to be cheap.
GPL requires providing the source code via a medium customarily used for software interchange. Deliberately making it inconvenient by using a medium no longer customarily used for software interchange is a GPL violation. Google Drive is already an unusual way to distribute software.
Google is already failing to provide the Pixel kernel drivers in the preferred form for modification. Their kernel build system uses Git commands but yet they aren't providing the Git repositories it expects to be there. They had to provide a repo metadata file as a workaround but it's not the same since the revisions of the code aren't set properly in the resulting build.
Google is arguably already violating the GPL. They're deliberately making it inconvenient and are adding deliberate delays through requiring manual handling of the requests.
Greenbar printouts.
I'm pretty sure there is a lot of code in Android that belongs to Google and is not part of an upstream GPL project. They would be completely entitled to stop sharing it.
Isn't that the point of Google Play Services? To keep their proprietary code separate, in a super-app that doesn't obey the GPL?
And you have to fill out a Google Form to get that link in the first place.
> I just want to get rid of forms. Like, I never want to fill out a form again.
The opening line from this interview with Sameer Samat on the Google for Developers YouTube channel in June.
https://www.youtube.com/watch?v=YvVsdZL2ogY
HE wants to get rid of forms, and make the rest of the world enjoy the burden of requesting access to open source code through a beloved form. Hope that's clear now.
> Prior to moving it to Google Drive, they started squashing the history into a single commit prior to pushing release tags. The tarballs provided via Google Drive have exactly the same source code. However, they went out of the way to make it more inconvenient in several ways.
Ugh.
Also I can't believe it's been 10 years since they shut down Google Code.
> ...after making a request through Google Forms This is even more ridiculous to me.
At this point, without Git commit history (assuming it is a bare code dump), is it still even possible to guarantee it is what Google says it is?
You can compare against old dumps.
Sometimes I wonder if randos peek in and see this terminology and think we’re all nut cases
> Google, this small tech company (correct me if I'm wrong), is peddling source code via tarballs on google drive.
What is the context for this? It's not clear from the linked social media post.
The Android kernel source code is in git: https://android.googlesource.com/kernel/common/
Plus there's a lot of other Android source hosted on Google's git servers: https://android.googlesource.com/
The repositories you have linked are not sufficient to build an Android distribution. In order to get the missing bits, you have to fill out a form: https://source.android.com/opensourcerequest and beg them, and if they decide you are worthy, they will email you a link to a tarball, which is hosted on Google Drive.
>The Android kernel source code is in git: https://android.googlesource.com/kernel/common/
That's the mainline kernel. Actual devices use various LTS kernels, for instance the pixel 9a uses kernel 6.1[1], which was hasn't been updated in a year[2]
[1] https://wiki.lineageos.org/devices/tegu/
[2] https://android.googlesource.com/device/google/tegu-kernels/...
There are other kernel 6.1 branches there, e.g. https://android.googlesource.com/kernel/common/+/refs/heads/...
I'm not sure which one the latest update for the Pixel 9a is using, I have an older Pixel 8. When I look at the Settings -> Android Version I can see it's using a build from January 2026 (also 6.1).
Reported here, among other places https://www.androidauthority.com/google-pixel-kernel-code-fo...
It's mentioned in the same thread, just scroll up a few pages in the linked social post.
Yes I read the whole thread, but it wasn't clear which bits of source code required requesting a tarball.
Don't be evil, right?
This is how a multibillion company that benefited infinitely from open source pays back.
Slogan is now "We didn't used to be evil"
Person A: Did you know Google removed access to Pixel code repo.
Person B: Well, it didn't go away, they just changed the access method to Google Drive.
Saved us that conversation here, Thanks. No matter what mental gymnastics we may do, it is pretty clear where this is heading.
On a different note, the source download form requires you to accept Google's privacy policy for the information you submit.
Is it ok to tack on accepting additional policies as requirements to access what is allowed under OSS licenses.
Google hasn't been able to properly do / fix Android gesture navigation for more than half a decade now. The amount that edge swipes in things like photo editing apps are detected as backswipes (sometimes destroying 10+ minutes of editing) is laughable.
Technically this is because a lot of apps thumb their nose at the requirement to have safe areas around swipeable elements in their app, but as a user, that is not my problem to fix. It's Google's.
The workaround is so ridiculously easy too: only allow backswipes to count in the lowest 15% of the bottom left of the screen. Yet despite having hundreds of engineers earning ±350.000 per year work on this problem for years, they haven't been able to either implement or even think of it.
The real fix would be to deprecate the three button layout in Android 18 and remove it in Android 19. Force apps to comply.
The other real fix is for apps to use the existing apis added in Android 10 to create regions where the OS will not prioritize navigation gestures over input to the app. https://developer.android.com/reference/android/view/View#se...
The real fix would be to bring back physical control buttons and leave the touchscreen for the rest.
Also, I have 6GB of RAM in my phone - switching from a browser to youtube, or vice-versa, should not cause the other to clear and start back again from a freshly-loaded state.
350,000 a year and people can't even get basic things to operate properly. Google needs broken up and their engineers need to go back to the 90s and learn some real programming skill.
I think you are grossly minimizing the effects on your change on both users and developers. Neither are going to comply and then you have further fragmented the user base and removed a bunch of apps.
I use an Android tablet and I only backswipe at the upper left.
3 years, checks out. Probably buddy buddy with someone. Reminds me of that 3rd Google Pay they made that they had to sack because it was so dumb.
What's Google got to do with GrapheneOS?
[dead]
This is absolutely not a witch-hunt. People in that position wield enormous power and take their paycheck and responsibility that comes with it. Linking to his professional linked in relation to his responsibility is nothing but professional.
Why not, his linkedin profile is public and easily findable. This is not doxxing.
anything but holding people accountable for their anti-consumer actions
Well, sounds like you have a rather weird definition of accountability. You do you.
He's the head of Android ecosystem; who else is accountable?
It's quite painful to resolve cognitive dissonance, so I understand the downvotes for your comment.
People are clever enough to reach high level corporate roles, but at the same time they're are too weak to emotionally process the consequences of their "work" on their human cash cows of below-average intelligence.
However with these kind of moral/ethical questions, it's really hard to draw the line.
Is working at Google and thereby facilitating the scamming of my grandmother worse than being an ordinary pickpocket or an lobbyist for big oil?
If you are worried about internet witch-hunts I'd stay away from the "creators" and content that Google platforms and makes money from on Youtube.
I think it's a stretch to call OP doing a "witch-hunt" here. That Android guy is a mini LinkedIn celebrity with 100k followers.
This doesn't excuse a message that literally reads like call to action.
Public companies and their executives deserve the same treatment as the government and the politicians. It is completely fine to let them know that the people are upset with their decisions.
I'm just thinking that someone who has 100k LinkedIn followers might be happy about any type of engagement, including nerdy rage bait.
What would be wrong with a call to action addressed at someone likely in a position to stop this bullshit if he cared enough?
[flagged]
I get that you don't like Twitter/Facebook/Reddit or whatever, but a clear solution to this problem is to hurt googles public image as much as you can and for that you need a platform with as large of a reach as possible.
edit: they have X but didn't post it there https://x.com/GrapheneOS
They post on Twitter more than anywhere else. This was a reply not a announcement or post. There are likely similar replies to this on their Twitter. Their communication is a goldmine for privacy and security info so even replies can be interesting enough to start discussion.
They have official chatrooms on Matrix and Discord and a forum on their website. They have unofficial (but run by them) chatrooms on SimpleX and Telegram and maybe other platforms idk.
They are not about avoiding big tech specifically, they make practical choices to improve privacy and security of their users.
Here's a statement with some ethos.
https://nitter.net/GrapheneOS/status/2044440381803069778#m
This wasn't an announcement with any new information. It was a reply to a question with existing public information. We've repeatedly posted the same information on X in response to similar questions.
This is very exciting. I have been an iPhone user for the last 8 years. I am entirely in Apple's ecosystem.
I would legitimately change my phone (+watch +headphones) for a vertical foldable (like razr) phone running graphene OS. I don't think Apple is releasing a vertical foldable or even a modern smaller phone. One can only hope.
To get you started on switching the ecosystem, which is a pain. Here's some of what I landed on while moving from iOS to GrapheneOS.
Ente Photos
NotesNook
Signal (I use Molly but it's only on Android)
Bitwarden
Proton
Looking forward to this! Google is not competent enough to sell Pixels worldwide, it's a pain in the ass to buy one!
Anyone has any idea if this changes current situation with nfc payments? Currently many banking apps do not work, and google pay is just unavailable, to my understanding it was related to secure chip on phone - as graphene wasnt "stocked" android os approved by google, i dearly hope this chnages with motorola
Tap-to-pay is available on GrapheneOS via Curve Pay in the European Economic Area + UK, PayPal in parts of Europe and many European banking apps. Google Pay will likely continue banning using GrapheneOS for the foreseeable future until regulators crack down on Google's overall anti-competitive behavior with Android and Google Play.
90% of banking apps do already work on GrapheneOS:
https://privsec.dev/posts/android/banking-applications-compa...
A growing number of the apps banning using GrapheneOS are choosing to start permitting it. A small number of apps are permitting it by relaxing their Play Integrity API checks but most aren't willing to do that. A growing number of apps are implementing support for standard Android hardware attestation and permitting the GrapheneOS verified boot keys with it. We provide a page guide explain how to do that:
https://grapheneos.org/articles/attestation-compatibility-gu...
Our partnership will Motorola will help get the apps banning GrapheneOS to start permitting it through GrapheneOS becoming more mainstream and eventually being considered the stock OS on certain device variants.
I hope it just me, but honestly I’m EU citizen, and wasn’t able to get through curve verification process. No reasonoble support.
Revolut for example works but many other banking apps rely also on high level of play integrity, as you describe.
I wish ppl behind this fantastic os strong nerves, you fight our freedom. Its appreciated.
I have a GrapheneOS phone and I pay with Curve.
I had plenty of troubles with curve, garmine watches is alternative, but fingers crossed that motorola phones works better
[dead]
Me too.
My two requirements for a device are:
* Being able to pay for stuff
* My blood glucose sensors work (Librelink)
If they worked on a dumbphone, I'd have a dumbphone.
Tap-to-pay is available on GrapheneOS in Europe. Your profile implies you're in the UK where Curve Pay is available. There are also banking apps in the EU with working tap-to-pay but we aren't sure if any of the UK banks provide it without Google Pay.
90% of banking apps do already work on GrapheneOS:
https://privsec.dev/posts/android/banking-applications-compa...
> If they worked on a dumbphone, I'd have a dumbphone.
A dumb phone won't provide any form of secure calls or texts. People should migrate away from carrier-based calls to the extent possible rather than towards it. A dumb phone is also entirely reliant on cellular instead of being able to use Wi-Fi instead.
I don't doubt they will cost more than the Pixel line, but I'm somewhat skeptical that the hardware will be higher quality. Perhaps my idea of what Motorola is capable of is outdated.
Google’s Tensor chipset is weak by modern standards, and Motorola is taking the strongest off the shelf processors from the best mobile chip designer (Qualcomm).
Plus the Samsung Exynos modems that they were using from Pixel 6-10 (11 switched to Mediatek) had worse power efficiency and performance vs Qualcomm.
So...what's your comment? Opposing Motorola's comment, in that they already buy the best? Supporting, in that their standards haven't dropped?
Comparing GrapheneOS on Google’s Pixel vs Motorola’s new phone. (I expect Motorola’s future offering to be more performant.)
Realistically, most smartphones are made by the same ODMs. Since they don't make their own screens, shells, CPUs or modems, the only thing being set apart is the software.
Except that it's all Android?
I'm not selecting which phone I buy on whether the stock OS comes with lockscreen shortcuts. At best, a software requirement someone might use as a deciding factor is OS support and bootloader unlock. The real differences are in hardware: size, battery life, chipset speed, RAM or other local model enablers, picture quality (this part also depends on good software to be fair), included accessories, satellite connectivity hardware, headphone jack, gimmicks like UWB or FM radio support, whether it's a flip/fold phone, storage space / sdcard support... all hardware differences
> Except that it's all Android?
If only this were true. Samsung makes arguably the best hardware, but I refuse to buy a phone with Facebook pre-loaded and unremovable, a second (worse) app store preloaded and unremovable, and a bunch of redundant samsung-branded copies of the google apps. The best android images are as close to vanilla AOSP android as possible -- this used to mean Sony or Google branded phones, except Sony doesn't really market phones in the United States anymore and the Pixel phones are diverging from AOSP
The good news though is that by replacing the Pixel's stock OS by Graphene, you get something close to AOSP and arguably better. The hardware is nothing to write home about, but the phones are well priced and the bootloaders are unlockable.
I'm writing this from a Samsung. Their store software hasn't ever gotten in the way and I like most of the UI changes they made besides the extra apps that you can mostly hide or remove (in my case especially because root, but alas I'd not encourage anyone to buy Samsung anymore without the option to control the hardware as if you own it)
Not to defend Samsung specifically, just that most phones' software is fine after a bit of setup whereas you can't download more RAM (don't believe the scams that are out there! :P). Even on Huawei I remember there were some things better than on stock but forgot what specifically (the only thing that comes to mind was a lockscreen menu that you could open with a gesture and I used all the time)
Apropos Sony, that was the only brand where I kept having issues because my mom, who had the phone, constantly had questions about what to do with some notification that the OS was pushing and we couldn't get rid of. Basically product ads, iirc to try this-or-that app or function
I do get what you mean about bloatware, just that it's more of a tie-breaker (saving you an hour of debloating, assuming you stay on stock) as compared to the permanent differences in hardware capabilities
Pixel itself is very mediocre hardware, it's not hard to surpass. The battery is my main problem with it, my current pixel can't barely survive half a day of usage.
Anyone want to place bets in whether this will be an unlockable bootloader, or some GrapheneOS only install path?
Sure would be nice to have phones that can be rooted, or OS replaced. I've been hopeful this would perhaps enable that, but I fret my excitement may be premature.
Providing an unlockable bootloader with all of the security features intact for alternate operating systems is part of our hardware requirements. Our main requirements are listed at https://grapheneos.org/faq#future-devices which covers both updates and hardware security features.
If google allows that for pixels, I don't see why Motorola wouldn't.
Besides, GrapheneOS would probably don't want to get into a situation where their keys are burnt into hardware non-modifiable. They had to revoke such a key once in order to protect their users (against an attempt to hijack the project).
Providing an unlockable bootloader with all of the security features intact for alternate operating systems is part of our hardware requirements. Our main requirements are listed at https://grapheneos.org/faq#future-devices which covers both updates and hardware security features.
I wonder how Google will react if more and more mobile phones with GrapheneOS appear on the market. I suspect they will block further adoption by throwing up all kinds of hurdles.
They could make more parts of Android closed source, even critical ones without which you cannot realistically build an Android phone. It could, however, trigger anti-trust lawsuits, but my guess is they're willing to risk that. I mean, worst-case they only have to rollback to what they already had and maybe pay a fine.
What security feature is the 2026 Motorola Signature missing?
Hardware memory tagging and good enough secure element integration. Both will be there for the next generation.
Honest question, because I'm not part of that scene (yet) at all:
I seem to remember that I have read mentions of GrapheneOS for years now, but does this news mean it has been practically vaporware the whole time? Google making Android a walled garden just as bad as iOS shows how important projects like this and its siblings are. I'm impatiently waiting for more Jolla phones to become available, but something like GrapheneOS might be a viable alternative.
Stoked to soon be able to give these people money. The moment there's a device available I'll be checking closely to see if it meets my requirements.
Thanks to everyone who worked so hard to get here.
Are there banking customers in Europe who do not use mobile banking apps
Are there European countries that actually force, cf. coerce, banking customers to purchase mobile phones and run corporate mobile operating systems
https://en.wikipedia.org/wiki/List_of_countries_by_mobile_ba...
https://sqmagazine.co.uk/mobile-banking-statistics/
One approach is to use one phone (A) for banking and other commercial transactions and use another phone (B) for everything else, e.g., personal communication with friends, family, etc.
Phone A can run corporate mobile OS
Phone B can run alternative OS
Arguably, the data collection, surveillance and advertising exposure when using phone A is tolerable if that phone is only used for banking and commerce
The problem arises when someone tries to use a single phone for every general computing purpose
If that phone is running a corporate mobile OS, then that may expose the owner to an excessive amount of data collection, surveillance and, potentially, ads
I'm surprised it took them that long. I always found it odd that they would support Google phones only.
Pixels are the only devices providing the updates and hardware-based security features required by GrapheneOS. Motorola and Qualcomm are improving their hardware so future devices will all of our requirements. Motorola will provide us what we need to provide proper updates and is helping us port to their devices. We'll have their support to keep it working well. GrapheneOS needs a lot of hardware related work for our security features.
Our hardware requirements are listed here, but our features also need to be ported to the hardware such as getting hardware memory tagging working for the whole kernel and userspace:
https://grapheneos.org/faq#future-devices
I would love to have more vendor supporting GrapheneOS. I doubt that it will happen though as vendors would prefer to have control over the experience.
Let me know when you're trying to eliminate having a Google or Apple account to do anything instead of making it less intolerable/invasive to have one.
GrapheneOS works well without a Google account and has no built-in way to use one. Most apps work fine without one, but there's the standard issue of services requiring it for login. Having at least a throwaway account is also useful for the sandboxed Google Play Store but people also install those apps via Aurora Store which uses shared throwaway accounts.
I wonder if this could enable a samsung dex-style desktop mode
it'd be great if you could dual boot with grapheneos hidden
right now if you have it with you graphene just needlessly raises suspicions, its unjustified but thats what it is
GrapheneOS currently has around half a million users but the userbase is rapidly growing. The pace of growth will increase once Motorola flagships officially support it. It will increase far faster once lower end Motorola devices meet our requirements for updates and security features so we can expand to those too. Becoming an increasingly mainstream OS is the best way to address the narrative that using it is suspicious, but that's already nearly entirely fearmongering.
On Pixels, GrapheneOS isn't the stock OS and therefore the devices show a notice each boot with the fingerprint of the non-stock verified boot key. This is a standard security feature on the hardware and something we require to be implemented. Verified boot itself is extremely useful for protecting against both physical attacks such as data extraction and also persistence for remote attacks. The verified boot notice provides a way to verify GrapheneOS is genuine without trusting the computer used to install it. The verified boot key is stored in the secure element along with the OS version for downgrade protection. It's enforced automatically so it's not as if people need to manually check the fingerprint each boot, but it does have value in protecting against tampering despite this. It's a feature we want to have on our own hardware too, although GrapheneOS can eventually be considered the stock OS without the verified boot notice.
GrapheneOS is also clearly installed on the SSD. Every block of the data partition is encrypted on storage but the firmware and OS images are public knowledge and verified through verified boot rather than being encrypted. Putting another boot stage before the OS in order to encrypt the publicly available OS images wouldn't achieve anything since that would identify it as being GrapheneOS itself. The only way to hide the OS would be if the hardware itself had a firmware-based passphrase prompt and the first boot stage of the installed OS was encrypted along with the verified boot key in the secure element being wiped when unlocking. It would be possible to provide, but that would be specialized hardware and therefore it could be identified based on the hardware instead of the software.
The stock Pixel OS isn't designed to be able to be installed alongside other operating systems. It assumes it's the only OS and handles updating both the firmware and itself via the A/B slots. It would be entirely possible to have a main OS in those A/B slots responsible for updating the SoC firmware and acting as a bootloader for other operating systems. That would clearly be there on the SSD if that's looked at and would show the verified boot notice every boot.
> the updates and security features aren't as good [on lower end Motorola devices]
Having looked at some low-end Motorolas recently, this is accurate (albeit an understatement!)
How will this work? Devices will come with the bootloader unlockable or have to order through Motorola directly?
Did they solve widevine, hardware attestation and play integrity to deal with banks?
If they only "should" be available in 2027, that sounds like late 2027.
Iirc they said they will be able to release Android updates like Android 17, for example, at the time it's released. This year it was a few weeks until it came to stable.
This somewhat indicates to me it will be available when the Motorolas release which should be on their regular release patterns. That's been May for the 2025 and 2026 Razrs.
I’ll be surprised if devices ship after December 26, 2027
High end Motorola phones :((( where is my Graphene flip phone?
It's reportedly going to be available on the 2027 version of the Razr Flip https://www.motorola.com/us/en/p/phones/razr/razr-2026/pmipm...
It will likely be able to support the 2027 variant of the Razr Ultra. It may be another year before we can support the devices a step down from the flagships. It mainly depends on when the lower end Qualcomm SoC adds the security features we need, if Motorola switches to Qualcomm from MediaTek for more of the non-flagship devices and when Motorola can commit to providing longer updates for those. We're likely only going to support Snapdragon Motorola devices for the time being but it could expand further in the future when another SoC platform has what we need too.
https://www.motorola.com/us/en/p/phones/razr/razr-ultra-2026... is the Razr Ultra 2026.
Next gen of the Razr Ultra at least, according to another comment: https://news.ycombinator.com/item?id=49363702
This is good news but not so much good news for us poors. I was waiting four this announcement in hopes of getting away from google totally but with the 2026 Moto Signature going for $1000 I am sure the 2027 will be more so I will probably get Pixel 10 instead.
Maybe this will lighten the price on the Pixel 10's though...
Motorola's flagships are going to be their first devices providing the updates and hardware-based security features required by GrapheneOS. It will come to lower end devices but it will take longer.
Snapdragon 8 Elite Gen 5 is the first Qualcomm SoC with hardware memory tagging (MTE). MTE isn't even available on the slightly lower end Snapdragon 8 Gen 5. A lot of the SoC security features are segmented based on price and only the flagship SoC platform has everything we need. Snapdragon's upcoming next generation SoC is the first truly providing everything we need. There's still a lot of work to do since providing the features on paper is different from having those fully integrated to match what we have on Pixels.
If this is successful, I can see this trickling down to the lower end phones in the following years. If for no other reason than keeping their hardware as similar as possible.
https://news.ycombinator.com/item?id=49368750
All other phones will have a higher price tag due to memory hogging by datacenters. How much will that google pixel 10 be when the motorolla phone arrives?
How does the GrapheneOS threat model account for baseband or firmware-level supply chain risks on Lenovo/Motorola hardware, given their historical consumer security incidents like Superfish? Is the open-source attestation sufficient to mitigate hardware-level tampering?
Now if only there will be a normal sized phone (the old "normal") from Moto with such OEM endorsed kind of support of Graphene then I might as well let go of my fruit no. 17. Yes, I will.
[flagged]
Security-through-obscurity (i.e. using a custom ROM on a lesser-known device) does have some upsides, since you're less likely to be compatible with off-the-shelf exploits. But this is much less true now that LLMs exist, and anyone who can afford the tokens can port any exploit to any and all vulnerable devices.
Who maintains the kernel+driver trees used by the LineageOS port you're using? And what's the modem's security like?
Just gave me something else to be annoyed about today ("anyone who can afford the tokens can port any exploit to any and all vulnerable devices.")
Not sure that is exactly correct yet but guessing not long til it would be. Bleh.
I can tell you from first-hand experience that it is true already (Well, it's true for the specific exploit/device pairings I've tried, I've not tried to construct an omni-exploit)
Completely random public example: https://github.com/BuSung-dev/Root-My-Galaxy-Payloads/pull/1... (where GLM 5.2 is credited with the port) (Check out the other PRs in that repo for other similar examples)
[flagged]
If a state actor wants to pwn your phone, they don't need to orchestrate a complex inter-organizational conspiracy to get there.
I also don't need pay a lot of money just to use their compromised hardware.
Are you also one of those people who think AES is backdoored because the NSA recommends it?
A member of the NSA also provided the ECDSA P-256 curve seeds but totally can't remember why
It would be funny if it actually was intentionally selected, but for DES-like instead of Dual EC reasons, and they're just too embarrassed by Dual EC to admit it.
[flagged]
[flagged]
Since we're speculating here, I hope whatever phone you have allows you to lock the bootloader (My oneplus doesn't after installing LineageOS). And certainly NSA has no way of infiltrating AOSP or less hardened chipsets.
There has been successful honeypots like EncroChat. What's the evidence that GrapheneOS is not yet another one?
For one, GrapheneOS is open source, unlike EncroChat which was a shady proprietary app distributed on shady modified smartphones.
GrapheneOS also doesn't have any custom messengers or other services which could potentially be monitored. It's very easy to check where your phone is sending requests, and if Graphene was secretly MITMing all of your traffic it would be discovered within days.
Since more than a decade that MITM is not a mass event. It is a targeted event for selected users which are scored as having a low chance of discovering anomalous traffic. It first (publicly) started by government authorities sending fake updates to operating systems which then weaken the target machines or straight up RAT them.
Same case here.
[flagged]
[flagged]
>Of course they'll say they couldn't read it if they are after his contacts and network rather than after him.
From what a friend working in a state police cyber crime office says, "Cellebrite can't currently, unless its a Graphene OS user that's far behind on updates"
They also said iOS is equally safe unless you're an update or two behind.
GrapheneOS seems to do better than anything else at preventing AFU exploitation based on the leaks.
iOS will be quite good BFU but on iOS the auto reboot (brings phone to BFU after 72 hours without unlocking) is, well, 72 hours. On GrapheneOS it's 18 by default and can be as low as 10 minutes.
Good luck on that, Cellebrite :)
I ran Graphene without a Sim card for 2 months and as soon as I added a Sim card (with of course, difficult to vet networking) the phone is always hot and the battery life reduced by half. Might be a coincidence but also made me rethink how I feel about Graphene
> I ran Graphene without a Sim card for 2 months and as soon as I added a Sim card (with of course, difficult to vet networking) the phone is always hot and the battery life reduced by half. Might be a coincidence but also made me rethink how I feel about Graphene
Strange you're being flagged since it's easy to find many other people on the graphene forums reporting the same (unresolved) problem.
Doesn't mean it's guaranteed to be limited to graphene in scope, but definitely seems to be a prevalent issue for some yet-to-be-determined reason.
Possibly related, does anybody know if graphene is vulnerable to Pegasus?
My 9a running GrapheneOS doesn't get hot and battery life seems no different to other phones I've had the last few years.
That can also indicate you are not a PoI
It can also indicate you forgot to block the Phone permission etc on Google Play Services.
The easy explanation is that GrapheneOS users are obviously very interesting to Google and so they’ll slurp everything they possibly can, as often as they can.
I disable all Play packages in between installing the rare app on my (often elderly) users’ Graphene devices.
It would seem dwedge is likely a PoI in many jurisdictions.
You can ask on the forum for troubleshooting. Pixels just have bad performance unfortunately.
https://discuss.grapheneos.org
What Pixel do you have? Modem quality varies and signal strength could play a role. My 9a gets hot in areas with poor reception but is fine at work where I get over a gigabit down.
9. I left it with 70% battery for 5 hours and came home and it was red hot and dead. In a city with no reception issues.
That's definitely a problem, but if it was the standard experience of GrapheneOS users, then GrapheneOS wouldn't have as many fans* as it seems to.
*Fans as in happy users, not fans as in blowing cool air over a red hot device
That's strange. Have you tried the stock OS and had the same problem?
How many apps have network permission? Did you install anything from the play store at all? As a rule of thumb, the play store and everything on it is spyware.
I had the opposite experience. I was pleasantly surprised by the battery life you can get when your phone isn't full of shitware apps and even when you do install shitware, the OS helps you confine it.
It happens in every profile. Only one has the play store and is rarely used, doesn't run in the background
That happened to my pixel running stock android and it was the 5G. As soon as I disabled it the battery lasted longer and the phone was way cooler. After all, I'm totally fine with LTE speeds
Did you check the forums or research for any benign reason that could happen? I've run Graphene on Pixel 9 and 10 and never had such battery issues.
[flagged]
Because it doesn't spam you with dickovers suggesting you log in when you open the link. But you're not really interested in this, are you?
Tell me you're in a bubble without telling me you're in a bubble.
(Mastodon is, of course, also a bubble. But largely by design. A lot of more tech-leaning folks decamped there any stayed there)
EDIT: ah, OP is just a troll that only ever seems to comment when someone mentions a short form social media network that isn't Twitter.