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.
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...
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.
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.
Yes, by "upstream", I mean "upstream Android".
> Google didn't invent MTE or memory tagging.
Sure, they didn't invent memory tagging (SPARC ADI was an implementation from a decade ago, and I'd bet IBM had an implementation of something similar in like the 70s, judging by the rest of ISA innovations in the last decade), but they definitely invented the instantiation of it in ARM. Pretty much everything aside from instruction encoding for MTE was specified in a doc sent by Google to ARM in response to ARM telling Google something along the lines of "the entirety of our efforts in the security space are going to be spent on something that you're not going to see any benefit from within the next decade: CHERI aka Morello aka Arran".
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.
> We're legally allowed to provide compatibility with Google Play via our sandboxed Google Play compatibility layer.
maybe once that happens grapheneos will finally take anti-fingerprinting seriously.
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.
> hardware attestation, which is not fingerprinting
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)?
Blocking access to attestation or DRM will prevent using the functionality of the app depending on it or the whole app unless it's implemented incorrectly.
GrapheneOS does provide a toggle to block apps using the Play Integrity API because we found a small subset of apps using it are not yet enforcing providing a result due to being in the process of phasing it in. This doesn't apply to DRM or direct use of hardware attestation. We have a planned feature for blocking access to DRM as an attack surface reduction feature since it can eliminate a little bit of OS attack surface and a significant part of the TrustZone attack surface. Hardware key attestation has almost no attack surface and doesn't provide any info not available other ways.
> this is false, the attestation middleman Google server can fingerprint your unique device serial (in-silicon key) whenever it wants.
That's not how the hardware key attestation system works. Only key provisioning uses their service and if you don't trust their separation of the provisioning with the frontend, that's fine since we run it through our own frontend by default so they can't connect an IP with the provisioned key which would be the only real privacy issue. That's why they made a point of how they separated the systems for it, but you don't have to trust that on GrapheneOS. If you use a VPN it's irrelevant.
> 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.
That's not an accurate description. It's also implemented via our server by default too. If you use a VPN that's not relevant.
The MediaDRM ID is also widely misunderstood since it is scoped per-app rather than being global. The best way to address it is our planned DRM toggle.
> if you were serious about privacy you would provide the option to completely disable that functionality in grapheneos
We disabled DRM provisioning and usage by default in Vanadium years ago and have a publicly visible feature planned for providing a toggle for native apps being able to use it. We don't have unlimited resources to get everything we want quickly implemented.
> how many of your users are even aware that google can track them across factory resets (or anyone who has a license server certificate)?
You're making attestation and DRM key provisioning sound far worse than it is. It's not fingerprinting and it doesn't give them another way to track users in practice. If services want to share data with Google then they don't need any of this to do it and it doesn't inherently result in anything being shared with them that's in any way useful. We have a planned feature for providing a DRM toggle but it's nearly entirely wanted for security, not privacy, and there are bigger security features to implement. There are many planned privacy features which would make a major impact rather than near zero as this would.
Preventing fingerprinting by websites is a very hard problem especially considering things like using timing and performance measurements for it. That's going to be a priority for us. Doing it for native apps would require a massive amount of changes to get anywhere close to websites. We could add 100 features reducing fingerprinting for native apps without accomplishing anything significant. We're focused on privacy features with a larger impact.
> Blocking access to attestation or DRM will prevent using the functionality of the app depending on it or the whole app unless it's implemented incorrectly.
> That's not how the hardware key attestation system works. Only key provisioning uses their service and if you don't trust their separation of the provisioning with the frontend, that's fine since we run it through our own frontend by default so they can't connect an IP with the provisioned key which would be the only real privacy issue.
both remote attestation packets and DRM license request responses contain a unique hardware identifier that can be extracted with knowledge of the right secret information.
in the case of attestation, privacy CA and the verifier must collude to do this (technically, you need the ephemeral key provisioning packet + attestation packet + secrets). blind signatures were proposed to make this impossible and REJECTED. using a proxy/VPN does not prevent having your unique hardware identifier be attributed to the attestation in this scenario. also note how when you attest to google both the CA and verifier are one and the same...
with DRM I'm not even aware of any effort to not directly expose the KeyBox public key to a license server, and ANY app can make use of DRM API. you do need the license server's private key to extract the identifier however.
Permit faking hardware attestation by providing a remote attestation provider device that runs stock Android and a corresponding app. When app on GrapheneOS asks to be attested, that request gets routed via the cloud to the stock Android remote device. People will have to buy 2 phones, one running GrapheneOS that they actually use, one that runs stock Android that they can lock up in a closet plugged into power.
>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?
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.
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.
It's definitely planned for GrapheneOS to be sold preinstalled on devices, but it will also be possible to buy devices without it and install it yourself with our web installer. The details need to be worked out. The focus is currently meeting the requirements and porting GrapheneOS to the devices.
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.
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?
Because they will pull the rug here one day too. Why on earth should we trust them to keep this approach to their hardware?
After all, it might rain tomorrow - but you should still go outside today.
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.
In 2027, you will be able to use the Motorola flagships to run GrapheneOS.
Grapheneos is still based on Android.
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.
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.
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.
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.
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.
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.
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.
https://www.androidauthority.com/grapheneos-motorola-partner...
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.
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.
If you have GrapheneOS, you have the best mobile security you can get, period.
> Moreover, in my opinion, by buying Google phones you're feeding Google, and I, personally, would like to avoid that.
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
[1] https://privsec.dev/posts/android/banking-applications-compa...
source: I eventually got bankid on the phone in late 2025
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.
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.
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
AFAIK they make use of this: https://a-sit-plus.github.io/warden-supreme/integration/supr...
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.
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
AOSP is a Linux-based mobile OS. It runs fine on top of standard Linux kernels without downstream changes. Getting rid of the need for closed source userspace drivers for components like a modern Mali GPU can be done with AOSP and will benefit the most people that way. AOSP if many companies and others band together to do it. It could also happen due to government intervention due to Google's antitrust law violations, but that could be done poorly in a way that harms open source.
Rolling the dice on a new technology could wind up being much more favorable.
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.
I bought a /e/os Fairphone instead.
Why do you choose to die on that hill? It's ridiculous!
AOSP is open source and written by Google. If you strictly don't want Google, you don't use Android. But IMO it's a shame because AOSP is actually good.
You could argue that you don't want to buy a Pixel because that would be giving money to Google, but not giving money to Google does not help the good alternatives, does it? IMO, helping the good alternatives means supporting GrapheneOS. The bigger GrapheneOS gets, the more likely it is that they get to work with major manufacturers (they already work with Motorola, which is great).
If you buy a Fairphone and run LineageOS, you are still running Google code (AOSP) and you support Fairphone who do not seem to care so much about security (otherwise they would meet the requirements of GrapheneOS).
I'm actually curious if there's something I don't know about /e/
* (March 2026) Motorola announces a partnership with GrapheneOS Foundation - https://motorolanews.com/motorola-three-new-b2b-solutions-at...
That's debatable. /e/OS is mostly made of AOSP, which is made by Google.
> It is less secure than Graphene
Most definitely, yes
> but also leaks less data to advertising companies.
This is wrong. If you don't use microg on /e/OS or Play Services on GrapheneOS, then it's equivalent. If you use microg, it still contacts the Google servers even though it is an open source reverse-engineered implementation of Play Services. The added privacy there is to go through a proxy, which GrapheneOS offers.
I actually like it better to run sandboxed Play Services through the GrapheneOS proxy, because in my experience it works a lot better than microg.
Really, the only reason to use LineageOS or /e/OS (which are interesting project, really) is that you cannot run GrapheneOS on your phone. If you have the possibility to use GrapheneOS, there is no good reason not to do it.
Even worse, last time I checked the source code, it downloads Google's proprietary, obfuscated DroidGuard blobs (which they can change between requests) and execute it in the privileged microG process if an app does a Play Integrity request.
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.
So no, they are not "only met on a single line of devices", in fact Samsung gets super close, but they remove yellowboot support and cripple the device if you unlock the bootloader.
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).
Confirmed, he says it in video: https://x.com/GrapheneOS/status/2040887784253141142
Do you get manufacturer updates? My experience with /e/OS was that the Stock Android was up-to-date but /e/OS was 4 years behind, on a Fairphone.
> for reasons I do not understand, Graphene OS is very closely tied with Google hardware
One of the requirements is precisely to be able to add custom keys and relock the bootloader, in order to keep the Android security model. Most other phones don't allow that.
(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.)
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)
One of the core tenets of truly free software is that I as user must be able to run, access, edit, and view everything.
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.
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.
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.
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!"
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.
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.
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.
> 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.
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.
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.
Its not advisable to run anything as root, at all. Or expose access to it in any form.
You can make userdebug builds to access a form of root that doesnt undermine the entire security model, in ADB. Afaik this lets you access apps internal directories but is not recommended for production devices.
Awesome, so you're advising against installing GrapheneOS for anyone that wants control over their own data.
Sorry for twisting the words slightly, but that's the essence of the issue here, isn't it?
> Its not advisable to run anything as root, at all. Or expose access to it in any form.
And then you advise for exposing access to it in pretty much the same form I asked for before.
It'd be funny if it wasn't so exhausting.
Regarding the security model: So adjust the security model.
Any access that an app can have, should also be available to the user. Importantly, they should be able to access and modify any data.
The system documents/files app already has special permissions for that, there's no reason why it shouldn't have access to all files (accessible through the same unlock system as e.g. the security settings)
To be clear, I am NOT advising root access. I am not contradicting myself. I am telling you it is dangerous but still telling you how it can be done in a less terrible way. To withhold that info would be senseless gatekeeping. GrapheneOS supports being built as a userdebug image but that will not stop them from telling you how bad an idea it is to use it on a production device.
GrapheneOS will not be rolling back aspects of the security model. That would be a massive step backwards for privacy and security.
An app developer getting access to send my files to a random server somewhere? That's just a simple permission prompt, no unlock needed.
But me getting access to my own files? That's an absolute no-go. Even with adb and unlock, absolutely impossible
Seriously, you need to explain the difference. Because I don't see how apps being a one-way street (they can access my data, but I can't access theirs) is in any way reasonable.
That's GrapheneOS users and developers every time the topic comes up. I'm reading the thread and really admire the matter-of-fact tone you keep while calling out the illogical parts of each new attempt at justifying why GrapheneOS doesn't grant users full device access. Thanks for seeing this thread through!
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.
You use operating systems that have significantly worse security than GOS, iOS and even stock Android as your examples?
Also you literally are the owner with GrapheneOS, lacking security is not "full ownership." You can create your own build of GOS, you can modify it ahead of time, you can literally see all of the source code it's running.
Claiming GOS isn't true ownership is like complaining that you can't change your car's wheel alignment while driving it and saying it means you don't truly own your car.
It kind of is. A locked box with no key, is a very secure device with no utility. If I can't unlock the box ever, just because someone could steal my key and unlock it as well, doesn't make the box an example of a perfect security model.
The issue with taking away root access, and providing no alternative for modifying installed apps, it's just taking away rights from user. An app can modify its own data (which is fine), but a user modifying the data of an app is somehow a big no no. GOS also provides no proper firewall solution, other than the stupid VPN-based solutions available on Android.
If the intention of GrapheneOS is to serve the app developers and not the owner of the device, it should just say so.
The mind bending people get into to prove GrapheneOS' statements right. Do you realise GrapheneOS is a third party as seen from yourself? Their system updater can sure as hell install (and cause to run) any code they like
If you can't give yourself root but a third party holds all the cards, you don't have more agency than a scenario in which you can issue commands at the same permission level as the OS
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.
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.
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.
also, 'rooted' means you have root access, not that you run everything as root.
Which supports only Pixel devices.
I never treat my (Android) phone as secure anyway.
Also note that Motorola Mobility has stepped up to provide the needed hardware security features. So it will expand to a subset of Motorola devices next year.
But yeah, vendors maintaining their drivers upstream in FOSS projects would obviously make it easer
So, Android?
I use a Samsung too. The bloat, dark patterns and enshitification with every update are even worse.
Long term I would probably have more hopes in https://postmarketos.org/