Android users need to switch to Graphene.
Someone needs to create a Linux based mobile OS foundation - Google's domination is contrary to many large companies interests, and if Meta and many other such companies were approached, they may well donate large sums of money in their own strategic interests.
GrapheneOS is currently the blessed child. Like CyanogenMod previously. They are "permitted" to access to Google Play Services because their work hardening Android currently benefits Google.
Once Google feels like there is sufficient stability and compatibility with hardened memory allocator and tagged memory (and when they can get Qualcomm to support it across their range), they will make harder, until impossible, for Graphene.
An old article [1] but:
> Google’s Android—and [Open Handset Alliance] members are contractually prohibited from building non-Google approved devices
So to compete you'd have to create a compatible Google Play Services as well as find a supporting manufacturer. Samsung managed their own competing apps and store [2] for a while along with Tizen, likely for leverage or theoretical pivot. But has since dropped that effort.
[1] https://arstechnica.com/gadgets/2018/07/googles-iron-grip-on...
[2] https://arstechnica.com/tech-policy/2021/07/google-bought-of...
Your claims about this don't make sense. Google does not provide compatibility with GrapheneOS for Google Play services. They do not provide support for using it or fix the issues introduced in new releases.
GrapheneOS doesn't license Google Mobile Services (GMS), doesn't include it in the OS and doesn't have Google certification. It isn't permitted by the Google Play Integrity API device and strong integrity levels because it doesn't have a GMS license. Google doesn't offer any way for GrapheneOS to license it.
We're legally allowed to provide compatibility with Google Play via our sandboxed Google Play compatibility layer. Similar to APK mirror sites, we're also allowed to mirror the freely available APKs.
We've put enormous time into developing sandboxed Google Play compatibility layer and there's ongoing work to continue resolving edge cases we haven't covered. If Google wanted Google Play to be used outside of stock operating systems licensing it, they could make it work as a set of regular sandboxed apps without us needing a compatibility layer. Our baseline compatibility layer isn't doing anything they couldn't do themselves by making them apps handle being portable to operating systems not deeply integrating it into the OS with highly privileged access.
maybe once that happens grapheneos will finally take anti-fingerprinting seriously.
> and they are legally allowed to fingerprint grapheneos and block Play functionality.
No, and you also don't understand how the Play Integrity API is implemented.
Google has a bunch of monopolies tied to Android. Antitrust laws put limits on what they're allowed to do which Google has been egregiously violating for many years.
Google isn't legally allowed to pull a bait and switch with Android by changing it away from an open platform and open source project. They used Android being both of those things to build and expand monopolies in a bunch of areas. The way Google exerts control over OEM partners with Google Mobile Services licensing has already been found to be illegal in multiple countries and they're in the process of losing more court cases over it. South Korea found their terms to be highly illegal and Samsung is already largely free from their restrictions.
Play Integrity API enforces the Google Mobile Services licensing model. The licensing model and terms are highly illegal in countries with decent antitrust law. It has already been found to be illegal by the courts in multiple countries. EU and US have particularly strong laws where they're egregiously violating and that's going to have consequences.
Play Integrity API is primarily based on hardware attestation, which is not fingerprinting. The strong integrity level fully requires hardware attestation and services using it are migrating to enforcing that. Device integrity level requires hardware attestation for devices known to have a working implementation which is a major loophole but it's gradually being closed. Play Integrity API also has many software checks.
Play Integrity API software checks require having an immense amount of privileged access which means it's not very compatible with sandboxed Google Play without an immense amount of work which would achieve nothing. Tricking all the software checks won't make it start permitting GrapheneOS. It's not feasible to pretend the device is one without hardware attestation while avoiding it being detected that it's being faked. None of this can be feasibly bypassed in the long term without it repeatedly breaking and becoming increasingly impractical to bypass. Many apps already require hardware attestation via the strong integrity level and eventually Google will close the loopholes for the device integrity level.
> maybe once that happens grapheneos will finally take anti-fingerprinting seriously
It isn't fingerprinting and no amount of anti-fingerprinting will bypass it. Hardware attestation exists and it provides the device model and OS. It's also easy for apps to detect those in many ways. Apps can just look at their own memory and see the OS libraries loaded into them. The only way to pretend to be the stock OS even without hardware attestation would be making essentially no changes to anything since apps can look at a lot of OS libraries, etc.
Running apps in VM wouldn't solve anything either and will only work for apps which don't try to detect being in a VM and don't use hardware attestation or the Play Integrity API. We'll still need to support running apps on bare metal once we have VM isolation features since one of the main things apps doing these anti-tampering and attestation checks is trying to block is being run in a virtual environment.
giving the option to completely block attestation and DRM API would be a good start.
this is false, the attestation middleman Google server can fingerprint your unique device serial (in-silicon key) whenever it wants.the DRM situation is even worse as ANY app can fingerprint your device serial and I don't mean just the DRM ID. anyone who has a license server certificate can fingerprint the DRM key in-silicon.
if you were serious about privacy you would provide the option to completely disable that functionality in grapheneos. how many of your users are even aware that google can track them across factory resets (or anyone who has a license server certificate)?
Thanks for your hard work!
>> Google’s Android—and [Open Handset Alliance] members are contractually prohibited from building non-Google approved devices
>So to compete you'd have to create a compatible Google Play Services as well as find a supporting manufacturer. Samsung managed their own competing apps and store [2] for a while along with Tizen, likely for leverage or theoretical pivot. But has since dropped that effort.
What's wrong with the upcoming partnership with Motorola where they work with grapheneos to get it suppported, but it's not preloaded?
It's a nice effort, but without preinstalls you aren't going to capture the market except for the tiny percentage of enthusiasts which are maybe a fraction of a percent of the market.
Google needs to experience real competitive pressure, and you need preinstalls for that.
Same story for year of the Linux desktop. It's doomed to 5% or less of market share without preinstalls (which Valve & the various other PCs now releasing with SteamOS are changing)
But also, prohibiting OEMs from making or partnering with "non Google approved" OSes is ridiculous and I'm surprised that hasn't been challenged in court yet as an abuse of monopoly power.
> without preinstalls
GrapheneOS has an official partnership with Motorola Mobility which is improving their next generation devices to meet our requirements and helping us port GrapheneOS to those. GrapheneOS will be officially supported on those devices with Motorola Mobility providing us with the stripped down hardware support code we need to support their devices with proper firmware/driver/HAL updates.
A bunch of companies are already selling devices with GrapheneOS installed. Those companies can start buying the future Motorola devices supported by GrapheneOS and doing the same thing with those which they already do with Pixels. Motorola can also specifically sell devices to other companies to sell with GrapheneOS with official support from Motorola.
> prohibiting OEMs from making or partnering with "non Google approved" OSes
It has been challenged in court and ruled to be illegal in South Korea and elsewhere. Regardless, it's only an inconvenience and can be worked around. Even if Motorola can't sell devices with GrapheneOS in many countries themselves, those can still be sold by other companies and Motorola can sell devices to those companies at wholesale rates where they can match the price of the non-GrapheneOS devices. Other than Google, most OEMs aren't directly selling most of their devices anyway.
> They are "permitted" to access to Google Play Services because their work hardening Android currently benefits Google.
Very little in GrapheneOS has gone back upstream post-Copperhead.
> Once Google feels like there is sufficient stability and compatibility with hardened memory allocator and tagged memory (and when they can get Qualcomm to support it across their range), they will make harder, until impossible, for Graphene.
What are you talking about? Google doesn't use hardened_malloc, and they literally invented MTE.
> Very little in GrapheneOS has gone back upstream post-Copperhead.
Most of what we've landed upstream has been post-Copperhead. AOSP made it increasingly difficult to contribute without being an Android partner and it's nearly impossible now. We've contributed elsewhere including to the Linux kernel and PowerDNS. We don't try to submit security improvements to the Linux kernel anymore based on direct experience of it not being worth the effort required but we still submit patches for bugs. We're not interested in arguing with upstream developers about whether security improvements are worthwhile so we won't contribute those changes to projects not enthusiastic about it. We've made recent contributions to various projects we use including PowerDNS because they don't make it too difficult to contribute.
> What are you talking about? Google doesn't use hardened_malloc, and they literally invented MTE.
Google didn't invent MTE or memory tagging.
Pixel 8 launched in October 2023 as the first production device with MTE and GrapheneOS began using MTE in production later that month. Pixel OS still doesn't use MTE by default and only began offering a way to use it with Android 16 via Android Advanced Protection Mode (AAPM). AAPM only uses MTE for a few core processes and apps explicitly opting into it which are nearly non-existent. It doesn't use it for the kernel, most of the OS or almost any user installed apps.
GrapheneOS uses MTE for the kernel, all of the base OS processes including apps with a tiny list of minor exceptions to work around HAL issues and many users installed apps by default. It supports opting into using MTE for all user installed apps by default and then disabling it for the ones not compatible with it which are becoming less common in large part due to GrapheneOS users reporting issues to app developers.
> Android users need to switch to Graphene.
Doesn't GrapheneOS supports only Google Pixel smartphones now? For most of the users, that would mean changing their phones beforehand. And if we're talking about common people (especially not in US), it's not even everyone who can afford that. Moreover, in my opinion, by buying Google phones you're feeding Google, and I, personally, would like to avoid that.
The vast majority of smartphones don't allow installing another OS. Multiple Android OEMs have been restricting or fully phasing out supporting it. Among devices which do permit it, none have provided the hardware-based security features or driver/firmware update support needed by GrapheneOS beyond Pixels. Our hardware requirements are listed here:
https://grapheneos.org/faq#future-devices
GrapheneOS has an official OEM partnership with Motorola Mobility and a subset of their next generation devices will be provided official support for GrapheneOS. They'll be providing us with a more minimal form of hardware support code close to the standard Qualcomm and other vendor code, so it will be cleaner than Pixels. Our partnership with Motorola is non-exclusive so we're free to support other devices with the help of other OEMs interested in meeting our requirements, but no other OEM is working with us yet.
We can't use devices with an end-of-life Linux kernel, no firmware updates, no driver/HAL updates and no support for important hardware-based security features we use. Several devices of a lot of the way towards providing what we need and several next generation Motorola devices will provide it. Other OEMs can do the same.
Have you considered being less puritanical about these requirements? Surely there would still be strong benefits for many users on other devices which would only be able to run if these were relaxed.
Our requirements are for industry standard privacy/security patches and protections. We haven't set a high bar but rather have very reasonable requirements. There's nothing puritanical about requiring what we do for a privacy and security project.
Most people don't have a device permitting using another OS at all or without crippling functionality including security. They need to buy a device to use another OS as a production quality daily driver. The vast majority of GrapheneOS users bought devices to use GrapheneOS rather than using GrapheneOS because it was available for a device they bought without considering it.
We don't want people to buy devices which will stop getting privacy/security patches for the firmware, kernel, drivers and HALs after 2-3 years and are missing important security protections. If we support a device then people are going to buy it to use GrapheneOS. Few of the people who end up using it are going to be people who already had it.
We don't want to have a watered down form of GrapheneOS without the core protections including what we build with hardware memory tagging. Older devices which we discourage buying not providing all the current requirements is much different from adding new devices without those. Our recommended devices (Pixel 8 and later) provide all of the current requirements and we strongly discourage buying older devices without enough support time remaining or the current protections.
We have a serious OEM partnership because we stand by our requirements and haven't watered down GrapheneOS. An OEM working with us to improve their devices to meet our requirements and helping port GrapheneOS to those with full functionality is only possible because we don't poorly support anything able to run another OS.
GrapheneOS is open source and others are free to make incomplete ports to other devices under a different name. Many individuals and companies have done this and it hasn't gained any significant interested. It doesn't provide what GrapheneOS does and the expectations of our audience are much higher. Our audience doesn't want a device with 2-3 years of delayed security patches for the firmware, kernel, drivers and HALs follow by end-of-life.
That would all be worth it, but it's been a few years and Google did all the shitty stuff I was protesting anyways and Apple is getting worse.
I'm hoping we get those moto phones with graphene pre installed so I can actually send the right market signal. But what's fucked up these days is you can't send the right market signal. Meanwhile I talk about fixing shit at work and my coworkers ask "what's the value" or say "there probably isn't any money in doing that". Even for problems they are one liner fixes and that they agree we spent more time arguing over than it would be to fix it. I don't think it's a top down problem, it's a bottom up. Those are much harder to solve
Yes but they have signed up with Motorola so that is changing
https://www.androidauthority.com/grapheneos-motorola-partner...
> Doesn't GrapheneOS supports only Google Pixel smartphones now?
For good reasons. Most other devices arent secure enough to guarantee privacy. Especially not if loaded with a custom operating system (most devices don't allow to verify the boot chain with a custom OS)
> And if we're talking about common people (especially not in US), it's not even everyone who can afford that.
You can get a new Pixel 9a here in europe for around 350€ and it will be supported at least until April 2032
> Moreover, in my opinion, by buying Google phones you're feeding Google, and I, personally, would like to avoid that.
Google phones are surprisingly open and work well. Google takes a pro-user stance here that is extremely rare in the ecosystem, so why not support this product?
It's alright, whatever the reasons might be, but let's not pretend there are no other ways out. I'm content with newest LineageOS on my 7 year old mid-range Xiaomi. I don't mind the loss of privacy guarantee. I don't have to spend any extra 350 euros and lose the headphone jack in the process.
An end-of-life Xiaomi device with no privacy or security patches for the firmware, Linux kernel, drivers and HALs for years doesn't provide the bare minimum for protecting user privacy and security.
It would theoretically be possible to port it to a newer kernel but that's not within the scope of LineageOS. It doesn't do that so there aren't Linux kernel updates since the kernel branch has been end-of-life for years already. It would also theoretically be possible to rewrite all the userspace drivers and HALs, but it's not being done. The firmware is a different story since it's usually signed and requires vendor support. It's important too since it's exposed to remote attacks via cellular, Wi-Fi, Bluetooth, NFC, GPU (web browsers, etc.) and more.
> An end-of-life Xiaomi device with no privacy or security patches for the firmware, Linux kernel, drivers and HALs for years doesn't provide the bare minimum for protecting user privacy and security.
Your very rigid view of the world is so distorted to the point of being absurd. You know damn well that the vast, vast majority of spying on Android is done in userspace.
A good OS that allows you to remove permissions from apps and further isolate things does a lot for privacy.
I respect your desire to refuse supporting anything but pixels, but please don't pretend that alternate OS on old devices don't improve privacy and security.
Frankly, that kind of rigid attitude/black and white thinking might be why you find it so hard to collaborate with upstreams.
I don't think its rigid at all. Its important to continue to be able to receive security updates. If a device can't, mostly because qualcomm/firmware no longer wants to bother 6 months after release, it's DoA.
We don't go around telling people that it's OK to still run Windows XP for the same reason. Why is/should mobile be any different?
Stop being OK with manufacturers having garbage support. It's completely unacceptable.
The main issue is that OEMs make too many device models with unnecessary variations for carriers/regions and make too many changes to AOSP. It's extremely hard for them to properly maintain all of it.
Qualcomm offers up to 8 years of updates from platform launch. Getting around 7 years of updates requires OEMs to use the latest and great platform combined with paying Qualcomm a lot of money for long term support. It may cost a million dollars or more for each year of support. OEMs also need similar support for other components but that mostly means choosing decent components.
Providing proper updates has a cost most OEMs haven't been willing to pay. Pixels and Samsung flagships have been the exceptions. Samsung doesn't properly update most devices, only flagships, and it's still worse than Pixels in important ways. Samsung has also been closest to having all the hardware-based security features we need but doesn't let us use a lot of those due to crippling devices if they're ever unlocked.
Our partnership with Motorola Mobility partly involves them improving their devices to meet all of our requirements which was already largely happening. It also requires porting GrapheneOS to their devices and fully supporting Snapdragon again including having hardware memory tagging support on it for the first time. No one is currently using hardware memory tagging in production on Snapdragon let alone for the entire kernel and userspace as we do so it's going to be a lot of work. Motorola is going to be helping with all of this. They're also going to provide us more minimal hardware support code without unnecessary changes not needed for AOSP / GrapheneOS. A bunch of GrapheneOS features need to be ported and the device support code needs to be made compatible with our changes too including but not limited to fixing memory corruption bugs.
The dichotomy here isn't grapheneos or updates, it's grapheneos or android.
GrapheneOS uses all of the standard Android security features including hardware-based security features. It also adds major security improvements including features heavily based on hardware security features which are either entirely unused or barely used by AOSP or the Pixel OS. Heavily using hardware memory tagging, integrating our USB protection with the USB controller and other features are core parts of what makes it GrapheneOS. An incomplete port without all the standard security features or the GrapheneOS added security features isn't GrapheneOS.
GrapheneOS closely follows along with Android releases, Linux kernel LTS revisions and driver/firmware updates. It had an experimental release based an Android 17 after only 2 days of it being released earlier this month. It quickly made it through our testing process with many regressions resolved to our Stable channel. This is part of what makes it GrapheneOS and an incomplete port to another device without the same updates wouldn't be GrapheneOS.
GrapheneOS is open source. People can make an incomplete port of GrapheneOS to other devices using their own project name. It's not a port of GrapheneOS to another device without having all the features and updates.
We phase in new hardware requirements for standard security features and the older generation devices without those are eventually gone. Adding a new device without hardware memory tagging would be far different than still supporting 6th/7th gen Pixels without it since we strongly recommend against buying those devices anymore and they're going to end up end-of-life.
But on a Linux kernel that old userspace is kernelspace. There have been so many privilege escalation exploits in the kernel since then there is no difference. Every app you install effectively runs as kernel or root if it wants to.
> Your very rigid view of the world is so distorted to the point of being absurd. You know damn well that the vast, vast majority of spying on Android is done in userspace.
Most local privilege escalation (LPE) attacks used to escape the app sandbox, browser renderer sandbox or other sandboxes are done with kernel exploits. There are plenty of LPE vulnerabilities in AOSP userspace code but plenty in the userspace driver and HAL code too. It's definitely the kernel ones which are used most in practice. There are an endless stream of serious Linux kernel vulnerabilities and regularly patching the kernel is crucial to privacy/security.
Nearly all data extraction attacks are currently done with Linux kernel USB exploits and will likely need to switch to Linux kernel radio and other driver exploits when the USB attack vector is unavailable. If you care about privacy then you probably care about protecting your data from someone who obtains your device. That heavily depends on both hardware-based security features and security updates for the firmware, kernel, drivers and HALs in addition to the AOSP portion of userspace.
Disk encryption doesn't truly work on most Android devices for the majority of users because they're missing Weaver throttling support in hardware so a random 6 digit PIN can be easily brute forced once an attacker gets control over the OS. Most users don't use a strong passphrase so Weaver is critical for them. A software rate limiting implementation doesn't hold up to serious attacks.
> A good OS that allows you to remove permissions from apps and further isolate things does a lot for privacy.
Privacy depends on patching privacy vulnerabilities and shipping the standard current generation privacy protections. Android 17 without our improvements has a decent permission model and app sandbox. That's not the case if there are a bunch of privacy holes in the kernel, missing privacy features due to an outdated kernel and privacy holes in the drivers/firmware too such as tracking via Wi-Fi identifiers other than the randomized MAC.
Privacy also heavily depends on security. That's why GrapheneOS puts so much work into security rather than only privacy features. Having a nice privacy model doesn't do any good if adversaries can exploit the OS remotely, from a malicious/compromised app or another way. It doesn't provide any protection for users against many widespread attacks. Play Store regularly catches and bans a lot of apps which use LPE vulnerabilities to take over people's devices. Far more happens via distribution methods without app store review or scanning systems.
We heavily improve privacy with features like Contact Scopes, Storage Scopes, Sensors toggle, Network toggle and other changes. These improvements aren't anywhere close to the highest priority on a device missing crucial privacy and security patches. It's better for someone to have a stock Android device with decent updates than a partial port of GrapheneOS with many of the privacy and security features miss
> I respect your desire to refuse supporting anything but pixels, but please don't pretend that alternate OS on old devices don't improve privacy and security.
Using those devices with LineageOS has nowhere close to reasonable privacy or security. You're missing years of Linux kernel patches, not only patches for the drivers, firmware and HALs. Not patching Linux for years is definitely important and it's not hard to exploit it if it's not getting basic updates, especially without having a lot of kernel hardening. Linux kernel exploit protections are far weaker than Android userspace exploit protections. It's the softer target and has far more privileges so that's what gets targeted. It has massive attack surface for apps despite the massive attack surface reduction done by Android. Android's standard exploit protections including attack surface reduction for the kernel are drastically better in the latest stable releases. It's not only the privacy/security patches which are important but also the standard privacy and security improvements.
The purpose of GrapheneOS is not making a highly insecure device somewhat less insecure while also making it less secure in other ways by losing verified boot and other security features.
GrapheneOS certainly doesn't refuse to support anything other than Pixels. We have an official OEM partnership with Motorola Mobility. We're working with Motorola on multiple devices meeting our requirements and providing official GrapheneOS support which should be available in under a year. You're claiming we aren't doing one of the major things we're actively working on and have announced with Motorola. We're also open to working with other OEMs once we have more resources available. It's not an exclusive partnership, but we're very busy and don't want to spread ourselves too thin.
So far, no other OEM has been both willing and able to make devices meeting our requirements so far. Samsung could do it but currently doesn't allow another OS to make use of many important security features right now since. Samsung permanently cripple devices if they're unlocked and locking it again with the stock OS doesn't restore all the functionality including security features, but even more security features are missing for an alternate OS than what's permanently disabled. They also make it extremely difficult to properly support their devices. They're welcome to change all of this and we could support their devices in the future.
An objective and accurate assessment of the available options is not absurd, its the bare minimum.
As the userspace improves, more attacks will be (and are) directed at the kernel, the linux kernel is already really bad for security, and it is absolutely vital to keep updating due to its architectural deficiencies and constant issues.
Alternative OSs on subpar hardware do not improve privacy or security. They do the opposite. Other hardware does not provide vital hardware security features, and many OEMs do not provide yellowboot or any proper way to relock the bootloader with another OS. Verified boot is very important for security.
Note that the OEM provides firmware images, an end of life device can never be secure because it lacks critical firmware updates.
This isnt subjective, this isnt rigid, and this isnt a matter of attitude. This is fact.
So to avoid google's android I buy google phone to not run android?
Yes, currently Pixels are the only phones with support for the hardware security features GrapheneOS requires.
In 2027, you will be able to use the Motorola flagships to run GrapheneOS.
Grapheneos is still based on Android.
> Google phones are surprisingly open and work well. Google takes a pro-user stance here that is extremely rare in the ecosystem, so why not support this product?
Because they will pull the rug here one day too. Why on earth should we trust them to keep this approach to their hardware?
The vast majority of smartphones don't allow installing another OS. Multiple Android OEMs have been restricting or fully phasing out supporting it. Among devices which do permit it, none have provided the hardware-based security features or driver/firmware update support needed by GrapheneOS beyond Pixels. Our hardware requirements are listed here: https://grapheneos.org/faq#future-devices
GrapheneOS has an official OEM partnership with Motorola Mobility and a subset of their next generation devices will be provided official support for GrapheneOS. They'll be providing us with a more minimal form of hardware support code close to the standard Qualcomm and other vendor code, so it will be cleaner than Pixels. Our partnership with Motorola is non-exclusive so we're free to support other devices with the help of other OEMs interested in meeting our requirements, but no other OEM is working with us yet.
We can't use devices with an end-of-life Linux kernel, no firmware updates, no driver/HAL updates and no support for important hardware-based security features we use. Several devices of a lot of the way towards providing what we need and several next generation Motorola devices will provide it. Other OEMs can do the same.
[flagged]
> copy your response
To avoid writing the same thing a 2nd time without forcing people to use a link and lose their place where they were reading.
> barely answers the question
We fully answered the question by explaining why we currently have to use Pixels and why we won't depend on Pixels anymore in less than a year. You're ignoring our explanation of our Motorola Mobility partnership. It explains why we need the partnership instead of adding support for devices without it too.
> But you answered with your text about how other smartphones don't have important "hardware-based security features".
No, we explained most devices don't even allow another OS and many of the ones which do cripple functionality including security so we can't support those. We also explained we need firmware, kernel, driver and HAL updates for a reasonable amount of time. We need the hardware-based security features we use to implement the core protections provided against attacks. It wouldn't be GrapheneOS without solid protection against remote attacks, apps and data extraction. We linked to https://grapheneos.org/faq#future-devices which lists out what we need. It's strange to ignore updates or put scare quotes around something we provided a detailed explanation for in the linked content.
You can't trust Google not to pull the rug. That's a big part of the reason GrapheneOS now has a deal with Motorola for the next generation of devices.
Don’t defeat yourself in a one person battle.
After all, it might rain tomorrow - but you should still go outside today.
My stance isn’t “give up.” My point is we should explore and expand non-Google alternatives for hardware.
they are already pulling the rug. Google took months to publish devicetrees for the Pixel 10. they've signaled (iirc) that they'll no longer make the Pixel line capable of running AOSP. the reason they even did at first was to make Pixel a reference implementation that vendors could use to port Android, but now they've announced a switch to an emulated device for that purpose.
The reality is that these types of problems affect too few people to matter. No appreciable amount of people will switch, or are even capable of it. And even if you made it a no-brainer, most people aren't going to change the OS that came on their device, warranty or not.
I tried. But then I didnt get access to essential services like banking and national resources.
FWIW, I submitted an EU DMA complaint (Art 27 report) against Alphabet for unfair gatekeeping against third-party distributions like GrapheneOS via Play Integrity. More info: https://github.com/AlexAltea/blog/blob/master/posts/2026-06-...
Convincing developers, especially bank and gov apps, is near impossible and won't scale well. Going after Alphabet for not meeting DMA obligations seems the easier path. Might not go anywhere but worth a shot.
Is there something we can do to support your efforts?
Only two things come to mind:
1. Provide or find pro bono legal resources deeply familiar with EU DMA and similar antitrust regulations, willing to proof-check and improve this report, and perhaps advise on better channels to submit it.
2. Locate more affected end-users, including applicable members of the GrapheneOS Foundation and developers behind other distributions, make them aware of these efforts so that hopefully we submit a joint complaint. (Might get more traction, though AFAICT reporting is limited to EU citizens).
Happy to fork this into its own repository if it helps with collaboration.
1. I will look into that.
A heads-up: the FSFE has already submitted a case for device neutrality regarding both, the ability to completely uninstall AI features and the unlimited interoperability decoupled from ADV: https://fsfe.org/news/2026/news-20260615-01.en.html
“Interoperability must be decoupled from developer verification procedures. We need clear, precise, and inclusive rules to prevent circumvention by gatekeepers and to ensure that interoperability becomes a concrete reality in practice” states Lucas Lasota, FSFE Legal Programme Manager
I can tell you it has NOTHING to do with developer, but more the business/content protection people say unlocked bootloader is not secured.
GrapheneOS runs with a locked bootloader. You temporarily unlock during installation but after re-locking, boot integrity can be validated against GrapheneOS' verified-boot keys. See: https://grapheneos.org/articles/attestation-compatibility-gu...
> Convincing developers, especially bank and gov apps, is near impossible and won't scale well
Not impossible though, my bank and govt eID app did do safetynet, but after enough users complained in both apps you can now skip a warning and use it without issues
The government and bank in question deserve to be named and praised.
Austrian eID app (ID Austria) + Erste Bank/Sparkasse AG (George Austria)
AFAIK they make use of this: https://a-sit-plus.github.io/warden-supreme/integration/supr...
Graphene OS user here. Almost all of the apps I tried work fine. All the banking apps I use work. Have you tried reaching out to the app developer or the service and explaining what Graphene OS is and asking them to support it? I was able to persuade one app to do it.
[1] https://privsec.dev/posts/android/banking-applications-compa...
Problem is that all banks require a national centrale controlled service for login (BankID in Norway). And it is this service that I cannot get to work running GrapheneOS. It worked a couple of months ago, but not anymore. And all customer services and complaints are directed to your bank who 1) has no idea what i am talking about and 2) no control over BankID verification requirements.
I did actually alert BankID about this potential lock-in issue back when they announced they would be abandoning the SIM-based (and thus phone-independent) solution, to little understanding and just general comments about the cost of keeping the SIM-based solution alive. I guess now with eSIM being prevalent it wouldn't have made much difference anyway.
But just the thought of the potential to be completely locked out of everything from banks to online payments, logins to the public health system, tax filings (and basically all public sector services) just at the whim of Google or Apple's automated algorithms misunderstanding some random account activity, is a thought that should make everyone (and especially those in countries dependent on systems like BankID) afraid and demand at minimum:
Rights to:
- Due Process
- Accountability from Google & Apple and fines for when they do wrong
- Multiple warnings (with a right to know what you're being accused of) before being locked out
- Well-functioning complaint procedures with strict time frames
- Make the mere concept of banning users "for life" illegal
...from Google and Apple (and strict fines for them not adhering to them). Feel free to add more to the list.
Else we as a society can't depend on a smartphone as the main key to our lives anymore.
Raise the issue with both the consumer protection watchdog and the trade watchdog. This is a monopoly issue that's impacting consumer choice.
I’ve nearly decided to switch back to the code brick instead of BankID app. It’s less convenient, but with the way things are going, I’m just not sure I want to exist in the digital world much longer.
Good idea. Maybe it wouldn’t be too bad to just attach the code brick to my keyring anyways.
I switched to GrapheneOS a couple months ago, and the only real downside is that MitID (danish verison of BankID) doesn't work. I got the code brick and attached it to my keyring and it's honestly not that bad, I usually have the keys close by anyway. Also most apps that need MitID allow you to create a pin to log in without reverification once you've logged in once.
99% of websites won't work with that one.
source: I eventually got bankid on the phone in late 2025
Correction: i did get bank access. I just couldnt log into the bank without a google or apple controlled device.
lol, this problem stopped me from installing GrapheneOS early. But now.. I removed banking apps by myself because my state require room them to collect phone fingerprint and access to location EACH time they opened. So... looks like now nothing stops me
I would say Ubuntu Touch + a Fairphone. Graphene is too reliant on Google.
I keep hoping for something more radical like Jolla and SailfishOS taking off or postmarketOS becoming a true viable alternative but as things are looking like now there's a better chance we'll ditch phones altogether in 10 years when smart glasses will replace them instead.
> we'll ditch phones altogether in 10 years when smart glasses will replace them instead.
Billions are spend right now to make sure the glasses also run Android or iOS. So far, Google, Samsung, Magic Leap, RealWear and Vuzix are working with/on Android XR, and obliviously Apple is working on AR/VR iOS.
Meta and a couple of smaller startups are doing something in-house, but I don't give them much chances to get an ecosystem going.
Honestly don't think that would be so terrible, with how bad and locked down the mobile ecosystem has gotten.
Rolling the dice on a new technology could wind up being much more favorable.
What /new/ technology? The basically same platforms. Just smaller phones with more cameras recording everybody without consent.
The only reason I have not switched Graphene is because for reasons I do not understand, Graphene OS is very closely tied with Google hardware.
I bought a /e/os Fairphone instead.
Give it a year, we may have GrapheneOS/Motorola then ...
* (March 2026) Motorola announces a partnership with GrapheneOS Foundation - https://motorolanews.com/motorola-three-new-b2b-solutions-at...
Those reasons are explained clearly and openly. Ironically, your /o/OS is way less open than GOS on Google hardware.
How is /e/ less open than Graphene? As far as I understand, they are both pretty open minus firmware that they can't control?
I'm actually curious if there's something I don't know about /e/
I just want to be as far from Google as I can. I do not want to buy google hardware. Graphene does not allow me to do that.
Not only you use Android OS developed by Google, somehow you choose a less open OS distribution, exposing you MORE to Google and their shit, only because you don't want to use their hardware that happens to actually be as open as it gets, including the firmware?
Why do you choose to die on that hill? It's ridiculous!
Pixels are consistently "third party Android builds friendly", plus GrapheneOS has a list of required security features (beyond their control): https://grapheneos.org/faq#future-devices
e.g. first one in the list:
> Support for using alternate operating systems including full hardware security functionality
GrapheneOS wants users to lock the bootloader (≈enable Secure Boot) after install by providing user signing keys (avb_custom_key) -- that already seems to leave only Pixel, Nothing and Fairphone.
https://github.com/chenxiaolong/avbroot/issues/299
Why don't they support Fairphone and Nothing, then?
These devices fall far behind the industry standard hardware security requirements GrapheneOS has.
I bought a second hand pixel when I had to buy a new phone. Still better for the planet than buying a new fairphone anyway.
It's because only Pixel devices have proper hardware security to build anything secure on top.
Hardware security is irrelevant to me. I just want to leave Google behind me. I do not want Google's hardware.
So you chose to use Google OS, still? What the hell? Just switch to Apple!
Sigh, /e/OS.
Your phone is running proprietary Google DroidGuard blobs in a privileged process every time an app initiates a Play Integrity request.
If you install some Google apps like Google Maps, they are run with more privileges than other apps (their microG fork gives apps elevated privileges when they match certain Google signing key fingerprints).
Also, your device is running a firmware bundle provided by Fairphone's Chinese ODM, including TCL image processing blobs. Your phone will soon run an ancient kernel and firmware tree with many known critical CVEs.
But this all doesn't matter anyway, because security hardening is only for spies and pedophiles according to the CEO of Murena (the company that makes /e/OS).
I know Graphene has innovative security measures, do you happen to know whether that includes anything wrt. phishing or social engineering?
(For those who haven't been following along: this whole affair started with phishing. People were social-engineered into installing an app and a little later their bank accounts were empty. A big issue in various poor countries.)
That's one of its primary arguments: besides the hardening against exploits, they're considered such a safe OS because you cannot access your data either and give the wrong app root access. Everything lives in a sandbox. Whether not being able to grant full access to e.g. adb shell, Termux, or Restic is what you want is a personal choice, but it adds a layer of security against any malware that tries to get you to grant them root access
This is also the argument they use to try to convince app vendors to add their keys to the allowlist, because the app makers can trust that their DRM will be active (if Netflix sets a "no screen recording" flag, you the user cannot circumvent it by e.g. reading /dev/fb0). It should have broader compatibility than other FOSS Android builds (when running the officially signed version of course, you can't compile it yourself and expect such apps to run there)
So it doesn't actually do anything to give control of the device back to the user?
One of the core tenets of truly free software is that I as user must be able to run, access, edit, and view everything.
You are free to make your own build of GrapheneOS with root access and have extremely reduced security. Just don’t expect support on the forums and waste everyone’s time when something happens.
"extremely reduced security"
That's such a fun statement.
Any security measures taken always remove agency from one person and give it to another.
iOS takes my control away, and in turn gives that control to Apple. GrapheneOS takes my control away and gives that to the GrapheneOS developers.
The "security" you're talking about doesn't prevent certain data from being accessed, it just changes who controls the access.
If the user cannot be trusted with their own data, then there is no solution anyway. They'll just tell their private data to a scammer on the phone instead.
There is no solution against a user that wants to give their own data away, but if you try to prevent that, the only thing you'll accomplish is destroying general purpose computing.
The sad part is that this has a solution. It's called adb root. Your adb stays locked unless you unlock it, and you're not able to get root on the phone. But you can through the adb shell, meaning that when app X wants to screw your data away from you you can still copy it. There is something deeply wrong about locking filesystems even from read access. GrapheneOS should at the very least give a full read-only access to the fs through (possibly) limited adb access.
Absolutely! Even if they require (like with bootloader unlock) adb and screen unlock for access.
That'd still allow you to free your data.
Ideally though the native filemanager should just have a sudo mode that can be entered to access everything, if desired.
Root access takes agency away from you and gives it to 3rd party software. It doesnt expand freedom at all, it just allows other software to abuse the user.
With a proper security model and verified boot, you can be certain you, the user, are running exactly the OS you expect to run. You can also properly revoke permissions to software and gate access as you see fit. With root, you cannot guarantee you are running what you expect and apps have to exploit much less to get root access, or just keep root access if given by the user. You cannot revoke godhood, it can just lie and say you revoked it. There is nothing enforcing any security features.
I just don't get why we need to argue about something — the right to general purpose computing — which has been answered decades ago?
The user must be the administrator of their own device. Whether that's a laptop, desktop, PDA, mp3-player, smartphone, tablet, cyberdeck, netbook, or any other kind of computing device.
The user must be able to overrule any and all decisions. That's the definition of ownership.
Like, this was the reason why GNU was founded, and before that was the plot of the movie TRON.
We're still arguing for several reasons, one of them is that people still confuse the user with the owner, as you do. "The user must be able to override" is implies that if you have physical access to someone's phone, you can install a keylogger before handing the phone back its owner. Nice for you but I imagine the owner might still quibble, even if you quote TRON.
If I hand my windows laptop to someone, they can also install a keylogger.
But no one said we have to copy that flawed concept. macOS and Linux already have a good solution, requiring your full unlock password in a privileged dialog to authorize changes.
It's ridiculous that changing the settings on my device is protected 10× more than transferring all my money to a random person.
Being the administrator and being able to sidestep OS protections are not the same thing. Without root, the user is in control of what application does what and how. With root, the user is not. Root is not freedom or ownership, like many try to claim. Root is a hacky shortcut to proper functionality. You can build and sign the OS with your own keys, without undermining the security of your device, and adding whatever functionality you want with the principle of least privilege.
Its really funny because Tron, or at least Tron Legacy, is a great example of why godhood is dangerous and why a user and a program having root access is catastrophic.
Being an administrator is being root. That's the entire point. That whatever restrictions an app has set, I can override it if I need to.
> You can build and sign the OS with your own keys, without undermining the security of your device, and adding whatever functionality you want with the principle of least privilege.
Building a version of the OS and flashing that removes everything currently on the device.
So if I ever need to overrule a restriction an app has set, I must have already granted myself the power to do so ahead of time.
Which means there are only two viable paths forward:
1. If I assume that software is perfect, and I will never need to overrule a restriction software sets, I can use stock Android or Graphene OS
2. If I assume that at some point in the future I might someday need to overrule any restriction, I must grant myself root permissions from the start.
Also, I don't need to grant root permissions to random apps.
All that's needed is for the adb and the native file manager to be able to enter sudo mode and read any file, so that in worst case I can always pull all data off the device, and flash a version of the OS with my changes instead.
If we want to go one step further, and want to apply the practical definition of the FSF rights of free software, you should also be able to replace any file using the builtin file manager in sudo mode.
You dont have the ability to guarantee you have overridden anything. The integrity of the OS cannot be verified and anything with root can lie to you that it was revoked. It does not put power in your hands.
Installing your own build does wipe the device when you unlock the bootloader, yes, but updating it with a locked bootloader does not. It would be a one time transfer if you have official images already installed.
Your paths forward are a false dichotomy. These are not the only 2 options. You can simply update your build with the changes you want.
The randomness of an app is irrelevant and apps need to jump through significantly less loops to obtain root access without your input. And even if they didnt do that, and you permitted root instead, the app can lie about you revoking it later in either case.
This is blind ideology over safety and real ownership. Root is a hacky shortcut for proper functionality, and is not a prerequisite to ownership in the slightest.
> Your paths forward are a false dichotomy. These are not the only 2 options. You can simply update your build with the changes you want.
Okay, so once I install grapheneOS, how do I update it with my own custom build while keeping my data intact?
> You dont have the ability to guarantee you have overridden anything. The integrity of the OS cannot be verified and anything with root can lie to you that it was revoked. It does not put power in your hands.
You haven't read anything of what I've written, it's incredible.
You're continuing to use the term "root" to mean granting full power to random apps.
I'm using the term "root" in Linux terminology.
It's not advisable to run random software as root, no matter what platform you are on.
But the OS' native file explorer and shell, in this case com.android.documentsui/com.android.files and adb, should allow the user to authorize themselves as root and read/write to any file.
>If the user cannot be trusted with their own data, then there is no solution anyway. They'll just tell their private data to a scammer on the phone instead.
Security isn't binary. Putting up barriers makes it harder for scammers to steal money. There's a reason why they exploit malware to steal money, rather than asking their victims to send them crypto directly.
> There's a reason why they exploit malware to steal money, rather than asking their victims to send them crypto directly.
The vast majority of scams literally work by them asking their victims to buy cryptocurrency or gift cards directly. Malware is exceedingly rare.
You know what would really help against scams? Avoid putting people in situations where they need to decide right now or they'll face punishment.
Modern society has created far too many situations where people need to react without being able to think through the consequences.
The only reason scams work is because there are enough actual situations with unnecessary life-or-death decisions.
>The vast majority of scams literally work by them asking their victims to buy cryptocurrency or gift cards directly. Malware is exceedingly rare.
Source? This article suggests otherwise: https://www.economist.com/interactive/asia/2026/04/10/scam-i...
Moreover it seems to be limited to south east asia for now. Just because you're in the US and all the scams you're getting is cold calls from microsoft tech support, doesn't mean scams with smartphone malware doesn't exist.
>You know what would really help against scams? Avoid putting people in situations where they need to decide right now or they'll face punishment.
>The only reason scams work is because there are enough actual situations with unnecessary life-or-death decisions.
In other words, "if we had world peace and everyone could hold hands and sing kumbaya, then we won't have to worry about scams!"
It is not an OS with bubblewrap, you can still mess up your privacy / security if you want to, that includes phishing and social engineering.
Is anything bulletproof against the user signing away their data? I think the question was whether it has any measures in this regard, not whether it's impossible to get phished
It's complicated… in a sense the bulletproof solutions are the ones that raise the cost of executing the attack above the average take. In another sense even they aren't bulletproof.
This particular attack requires getting users to sideload apps that would be rejected by the play store, and most users don't have developer mode enabled. Therefore, the cost of persuading someone to enable developer mode matters. If the procedure to enable developer mode changes from "open settings, scroll down, tap, scroll down, tap seven times" to include e.g. a 96-hour wait for developer mode to be enabled, then the cost of the attack rises by whatever it costs to stay in close contact with the victim for 96 hours, close enough to react if the victim comes close to realising the truth.
This isn't a guarantee. You can still get phished even if the phisher has to spend 96 hours in intensive contact with you. Some victims are worth that effort, maybe you are, and maybe the phisher made a mistake and puts in the effort to phish you based on the mistaken assumption that you're a millionaire.
There are also other things like that. If Google can ban the keylogger you use quicker than you can deploy new builds, for example. Still no guarantee.
> do you happen to know whether that includes anything wrt. phishing or social engineering?
Yes. For example if you install an apk from an unknown source (like a random website via browser or messenger) it will warn you what you are about to do and what effects that has.
You don't need to block stupid behavior. Just make sure users are well aware of their actions as long as they actually read warnings.
my brother in Christ, people who root their phones don't fall for "Hello sir, I'm sir John from Microsoft, you have virus sir, please do the needful install antivirus and send gift card sir."
Right, instead they download shady magisk modules that promise them free fortnite skins.
1) Anyone can fall for a scam. Especially those who believe they wouldn't fall for a scam. This is why ridiculing those who fall for [a] scam is harmful, and serves scammers. 2) You can root a smartphone for someone else's usage. For example, I can install pmOS on a smartphone and hand it over to my kid.
You’re right, they just fall for installing updates or CLI tools which install compromised dependencies and run wild on a rooted system before getting caught 24 hours later.
on their phones?
also, 'rooted' means you have root access, not that you run everything as root.
> Linux based mobile OS
So, Android?
yet another reason why the distinction between Linux and GNU/Linux is important
> Android users need to switch to Graphene.
Which supports only Pixel devices.
The resason is that only Google bothers to put enough hardware security features to build software on top that allows to make a really secure device that blocks tampering.
That's not a reason. When the hardware doesn't have those "security features", then don't "really secure", just run without being "really secure".
I never treat my (Android) phone as secure anyway.
Security is GrapheneOS's raison d'être. If you don't want security, you can run another Android build that does run on the hardware you have.
Well, they're not improving people's security overall by limiting themselves to Google's hardware.
I get it, but it really sucks that Graphene only works on Pixel hardware. I switched to Samsung with my last phone.
Out of the frying pan into the fire...
Korean manufacturers are even worse when it comes to privacy violations.
I use a Samsung too. The bloat, dark patterns and enshitification with every update are even worse.
Not really a solution at the moment if you do not want to give money to Google by buying a Pixel (hopefully the deal with Motorola will work).
Long term I would probably have more hopes in https://postmarketos.org/
Buy second hand
not possible in countries where they don't sell them, import fees are astronomical
I wonder if it makes sense to create an independent hard-fork of AOSP in the future. But probably the only option to keep this somehow maintainable is to replace many android-specific components with other userspace linux components that are already well maintained (systemd, networkmanager, wayland)
Would this not require some control over the hardware? Which would be difficult for the FOSS community?
maybe not, heck people reverse engineered apple hardware and implemented it in various FOSS driver stacks
But yeah, vendors maintaining their drivers upstream in FOSS projects would obviously make it easer
[dead]