[dryarzeg]

> 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.

[grapheneos]

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.

[arsome]

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.

[grapheneos]

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.

[palata]

Other projects (like LineageOS or /e/OS) have lower requirements. My experience is that it makes it very hard to know what kind of security you get. I have used /e/OS for a couple years before realising that it was signed with the Google test keys (so not signed) and the bootloader was not locked. And they were not forwarding the manufacturer updates, so Stock Android had the manufacturer updates and on my /e/OS they were 4 years old (!).

If you have GrapheneOS, you have the best mobile security you can get, period.

[khurs]

Yes but they have signed up with Motorola so that is changing

https://www.androidauthority.com/grapheneos-motorola-partner...

[godelski]

  > Moreover, in my opinion, by buying Google phones you're feeding Google, and I, personally, would like to avoid that.

I bought an iPhone based on that very decision. TBH, I regret it. The ecosystem is so locked down that I can't even sync my photos to my NAS without a hacky constantly breaking shortcut, building my own app, or paying for an app. Just to replace a small <50 line bash script that could do more than either the shortcut or any paid app I know. I'm constantly battling my phone.

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

[preisschild]

> 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?

[spaqin]

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.

[grapheneos]

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.

[tredre3]

> 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.

[thewebguyd]

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.

[grapheneos]

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.

[GoblinSlayer]

The dichotomy here isn't grapheneos or updates, it's grapheneos or android.

[galangalalgol]

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.

[grapheneos]

> 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.

[kalx]

Thanks for this. I wish it was an easy way to market this info to the wider non technical audience. It is a huge selling point for GOS that is difficult to package and make attractive (because it is difficult to understand / care about).

[HybridStatAnim8]

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.

[Forgeties79]

> 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?

[grapheneos]

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.

[cadamsdotcom]

Don’t defeat yourself in a one person battle.

After all, it might rain tomorrow - but you should still go outside today.

[Forgeties79]

My stance isn’t “give up.” My point is we should explore and expand non-Google alternatives for hardware.

[NoGravitas]

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.

[sterlind]

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.

[secult]

So to avoid google's android I buy google phone to not run android?

[Cider9986]

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.