I just installed Graphene on a new pixel. I've only used it for two days, but I got that same feeling of "finding buried treasure in your backyard" I got when I first installed Linux in 1999. I can't believe this amazing software is free in all senses of the word. It is a TON of work and they got so much right. The security and usability settings give all the grainular control I've known was possible and wanted for a long time.
I see some core team on this thread, so just wanted to say THANK YOU! Awesome job! Keep fighting for the users!
I'm totally the wrong person to offer recommendations on mobile, but so far it works very well for me, but then, I use almost no third party apps, and none of them are Play store only. My only complaint is the hardware (outside of their control).
I got it installed last weekend, really powerful mobile OS.
I did do about three weeks of research, as I worried that maybe a number of apps wouldn't run on it or needed some form of deep attestation. Didn't find much, OpsGenie and other work apps are happy with the GOS level of attestation provided.
Great to have Google kicked off the phone. So nice to shut off the network permission for any apps that only require an internet connection to serve ads.
One tip from me, if you came from stock Pixel: You can download the default Pixel sounds and set them up like it was. Have a look for "Your New Adventure" online, the message sound is "Eureka".
> So nice to shut off the network permission for any apps that only require an internet connection to serve ads.
For those of us who aren't ready to cut the umbilical cord to the mothership, you can also root/firewall on normal android to stop this. In fact I choose to not be able to use banking apps in order to cut out the crappy ads.
> For those of us who aren't ready to cut the umbilical cord to the mothership
You can use Google apps and apps depending on them on GrapheneOS via sandboxed Google Play. The vast majority of Android apps can be used. You don't need to stop using Google apps/services or other mainstream apps to use GrapheneOS. It's likely nearly all the apps you use or even all of them work on GrapheneOS. There's a per-app exploit protection compatibility mode toggle (and finer-grained toggles) to work around buggy apps with memory corruption bugs. We avoid turning on features breaking non-buggy apps by default and hardware memory tagging is temporarily opt-in for user installed apps not marked as compatible due to how many memory corruption bugs it finds.
A small number of apps are unavailable due to checking for a Google certified device/OS via the Play Integrity API. These are mostly banking apps, but most banking apps do work on GrapheneOS. There are tap-to-pay implementations which can be used on GrapheneOS in the UK and European Economic Area. Several banking apps recently explicitly added support for GrapheneOS via hardware-based attestation as an alternative to the Play Integrity API. We're pushing for more apps to do this and for regulation disallowing Google from providing an API to app developers for enforcing devices licensing Google Mobile Services. Play Integrity API often portrayed as a security feature but Google chooses not to enforce a security patch level. They're permitting devices with years of missing important privacy and security patches but not a much more private and secure OS. Only their strong integrity level has a patch level check, but the check is only done for recent Android versions and only requires they aren't more than 12 months behind on patches which serves no real purpose.
> you can also root/firewall on normal android
This is different from our Network permission which not only blocks direct access but also indirect access via APIs requiring Android's low-level INTERNET permission. Our Network permission also pretends the network is down through many of the APIs. For example, scheduled jobs set to depend on internet access won't run.
For those who don't want to root the phone, you can still avoid most of the ads by using a filtering DNS server with the Private DNS functionality on stock Android ROMs (or only at browser level if your favorite browser support DNS over HTTPS).
It comes with some minor usability issues with captive Wifi portals sometimes, but the trade-off of not having ads in app or while browsing is way worth it IMHO.
You can use RethinkDNS and avoid compatibility issues with captive portals. This is one of the options we recommend for GrapheneOS users. RethinkDNS is implemented as a VPN service but it has support for local filtering combined with optionally using a WireGuard VPN or multiple chained WireGuard VPNs. Android's captive portal handling works with a VPN and VPN leak blocking active since the connectivity checks are specially marked as not going through the VPN and so is the captive portal handling component opened by the captive portal notification. Private DNS is still missing support for this and also has the issue of causing DNS leaks for secondary profile VPNs.
Graphene has a really great sandboxed google servicen implementation, so barring a handful of banking apps not working, switching to graphene is a very gentle cutting of the mothership. For me it was very subtle, with better battery life!
The Netguard app worked well for me for that on vanilla burners and such. No root, "VPN" that I had block pretty much everything but the browser and Signal.
Even without root, a VPN-style firewall will work against all non-system apps. The downside of this approach is that you can't combine one with another VPN app.
RethinkDNS is implemented as a VPN service but it has support for local filtering combined with optionally using a WireGuard VPN or multiple chained WireGuard VPNs. You can have both via the VPN service API rather than choosing one or the other. No need for app accessible root access.
Yes. I used to run NetGuard, but Karma seems to work very similarly.
It looks like there's an app on F-Droid called "Rethink" that promises to do both firewalling, DNS blocking, and offers a WireGuard VPN. That seems promising, though I must add that I haven't tested it myself.
Rethink isn't quite ready yet. Depending on your use case you can go without getting thrown off by a bug for weeks, but when it fails it can be quite annoying. And don't use the GPlay version, but the FDroid or GitHub one.
On the other hand, the functionality is top notch. Easily the best integration of consumer level DNS + firewall blocking in any application on any platform. Just block everything of an application by default and then watch the connection logs for the app and start unblocking stuff via ips, domains or wildcards until the app starts working again.
RethinkDNS is implemented as a VPN service but it has support for local filtering combined with optionally using a WireGuard VPN or multiple chained WireGuard VPNs. You can have both via the VPN service API rather than choosing one or the other. No need for app accessible root access.
I use both adaway and AFWall+, as I don't like random apps making random connections, even if it's not for adverts. Once google play store ate my monthly data allowance, and it will never happen to me again.
> I can't believe this amazing software is free in all senses of the word.
I wish that were true, but if you delete the 100s of binary blobs (many with effectively root access) copied from a stock donor vendor partition the phone won't function at all.
There is no such thing as a fully open source and user controlled Android device today.
It's not all grim. GrapheneOS utilizes IOMMU to isolate the baseband and sandbox the wireless components. Even with binary blobs, the wireless radios cannot read encrypted traffic.
Sure, it's not perfect, but it's still really, really good. Even with the binary blobs that are on it, Graphene phones have been impossible to unlock via commercial cracking tools since 2022.
Laptops, desktops, smartphones or tablets are closed source hardware with closed source firmware in general. There are products marketed as if they're open source devices which are in fact closed source hardware with almost entirely closed source firmware. The software on top being open source is frequently misrepresented as the device itself being open source, which isn't the case. Not shipping important firmware updates in the OS provides assurance of insecurity while not changing the fact that the hardware and firmware is closed source. It has to do with a loophole defined in a certain ideology around software, not open hardware or privacy/security.
Laptops, desktops, smartphones or tablets are closed source hardware with closed source firmware in general. There are products marketed as if they're open source devices which are in fact closed source hardware with almost entirely closed source firmware. The software on top being open source is frequently misrepresented as the device itself being open source, which isn't the case. Not shipping important firmware updates in the OS provides assurance of insecurity while not changing the fact that the hardware and firmware is closed source. It has to do with a loophole defined in a certain ideology around software, not open hardware or privacy/security.
Plenty of laptops exist you can get away with running fully open source and auditable firmware, and a few that are mostly open hardware too, by the MNT Reform team.
The Precursor is the only pocket computer platform that is maximally open software and firmware but you revert back to the 90s in terms of power as a consequence with alpha quality software today. If Bunnie is successful with his IRIS approach and making custom home-user-inspectable ASICS then maybe a middle ground path can be forged in the next few years.
For now the only modern computing experience with fully open hardware and software I am aware of are the ppc64le based devices by Raptor Engineering, but at a very high cost due to low demand.
For those that want this story to get better, please buy and promote the products of the few people trying to break us out of dependence on proprietary platforms.
Anyways, we as informed consumers are hopefully all agreeing on striving for an open mobile OS and open hardware. For those of us, who consider themselves democratic, that is even an imperative.
All of those were closed source hardware with tons of closed source firmware. Not shipping firmware updates doesn't mean the firmware doesn't exist. There aren't open source devices in general. It's not specific to smartphones.
The entire point of Replicant was replacing all mutable closed software, firmware, and blobs with open alternatives and they did to a large degree succeed at that isolated goal.
Sadly this was, to your usual points, at the major expense of security making those devices purely research projects at best and not something anyone should ever actually use.
When you are stuck on a platform that requires closed firmware you are kind of stuck blindly accepting updates from the vendor to patch security bugs, stuck hoping they are not actually introducing new backdoors.
This is why I reject platforms that require closed firmware in the first place to the fullest extent I can.
The Librem 5 and Pinephone are closed source hardware with closed source firmware. It's a misconception that they're open source. They have open source drivers, not hardware and firmware.
SailfishOS is not open source itself. It's far less open source than Android which has the Android Open Source Project with the whole base OS.
I tried librem and pine a year or so ago. As long as it is basic phone use ( phone, text ), it is ok for daily use. That said, the experience is nowhere near ok experience in terms of speed or responsiveness, when compared to most basic android phones. I do not know if that changed since, but librem left a bad taste in my mouth based on how they seem to operate. Pine, by comparison, was a lot more honest about its limitations.
Yes, which is a huge problem. This is a big part of why Android phones suck so much ass - you're often stuck on old versions of android because the hardware vendors are too lazy to update their proprietary bullshit blobs that barely fucking work.
And now you're running a two year old phone and it's effectively obsolete.
If they would just upstream their firmware into the Linux kernel, you could upgrade these phones for years and years. Until the hardware is actually physically incapable of running the latest features.
Some vendors, like Google, promise to provide updates for a long time. But it's just that - a promise. There's no technical guarantee or mechanism for this, it's purely based on trust.
No production ready -mobile- hardware, I would agree.
The Precursor is promising, but software is not there yet.
I sit down at my desktop computer and send emails and type messages like this one. Then I get up from my desk and spend time with my family offline and present. It's pretty great.
People go through all sorts of weird mental gymnastics about this. The FSF at one point took the position that binary blobs were cool so long as they could not be upgraded, because then you could pretend they weren't software at all, but just part of the wiring. I've seen this odd line of thought attributed to RMS himself, but here's an FSF statement, from when he was running it: https://www.fsf.org/blogs/community/task2-openmoko
Let's not allow the perfect to be the enemy of the good. GrapheneOS does what it can to isolate those things as much as possible. It even makes good use of hardware features such as the IOMMU. It's a huge improvement on the status quo, even though it's not going to pass FSF RYF certification.
FSF RYF certification is anti-freedom, anti-privacy and anti-security. Pretending hardware is open because there aren't closed source components which are / can be updated doesn't make sense. They certify closed source hardware with closed source firmware. In many cases, privacy and security has been crippled to obtain the certification by preventing important firmware upgrades. Not shipping firmware updates in the OS doesn't mean the firmware isn't there and doesn't make the hardware or firmware open source. GrapheneOS wants to have actual open source hardware and firmware, not what the FSF is peddling. We certainly don't want to block people getting important firmware upgrades needed to defend devices. FSF heavily misleads people about these topics for ideological reasons.
Laptops, desktops, smartphones or tablets are closed source hardware with closed source firmware in general. There are products marketed as if they're open source devices which are in fact closed source hardware with almost entirely closed source firmware. The software on top being open source is frequently misrepresented as the device itself being open source, which isn't the case. Not shipping important firmware updates in the OS provides assurance of insecurity while not changing the fact that the hardware and firmware is closed source. It has to do with a loophole defined in a certain ideology around software, not open hardware or privacy/security.
Which Nvidia card do you have, and at which clock speed does your GPU run?
> With the right hardware choices running blob-free linux is pretty straightforward.
Unfortunately no. Features like SSE are pretty amazing and have made CPUs really fast and efficient, but they're unfortunately also large attack vectors, so vulnerabilities like Spectre or Meltdown occur. You need proprietary microcode blobs to fix those security vulnerabilities in your CPU.
Mock Location is a standard Android feature available in GrapheneOS. Our upcoming Location Scopes feature is being added for per-app control rather than global.
It's fairly pointless for apps to check for Mock Location being active without also verifying the OS via the Play Integrity API or hardware attestation API. Most apps checking for it are using or in the process of adopting the Play Integrity API. Apps enforcing the Play Integrity API basic/strong integrity level won't work on GrapheneOS unless they explicitly allow it. A growing number of apps doing this are explicitly allowing GrapheneOS. It would be counterproductive if our Location Scopes API didn't provide a way for apps to check if since those apps simply wouldn't permit GrapheneOS. However, it doesn't need to be the existing Mock Location API. It can be our own API which would only be used by apps explicitly choosing to permit GrapheneOS. This would allow apps like Pokemon Go and Ingress to permit GrapheneOS even if they insist on not allowing directly spoofing location.
My understanding is that Mock Location on android is a developer setting that apps can easily check for, and as such, is basically useless (it will not fool any app that is asking for your location).
It's a standard Android feature with various apps available for different use cases. Some are for setting a specific location, others are for using an external device. It's a very generic feature. GrapheneOS plans to add a different feature called Location Scopes similar to our Contact Scopes and Storage Scopes features for setting a per-app location. Android's Mock Location is global.
> Work profiles are inferior to separate user profiles, which are built-in to GrapheneOS.
Different use cases. User profiles are only active when you manually switch to them, while work profiles are active _alongside_ your main profile.
So for untrusted apps that you only use occasionally and on-demand (like the myriads of travel / shopping / random services apps), user profiles are great. For apps that you want to keep in the background, such as the proprietary messaging apps that all your friends use, a work profile is much nicer.
Private Space is very similar to a user profile but nested inside of another user. GrapheneOS adds shared clipboard control for Private Space which was the main disadvantage compared to a secondary user.
GrapheneOS supports having a Private Space in secondary users instead of only a single one in Owner. Supporting multiple Private Spaces per user is a planned feature at which point work profiles will be fully obsolete. The remaining use case for work profiles is to have both a Private Space and work profile in the Owner user.
Don't you have user profiles in Pixels? I can create another user an switch. Just not super convient.
Work profiles are actually pretty good good... For work.
Just to add to that: Even some proprietary applications let you download their APK right from the website. WhatsApp is one such example (I don't recommend that you use it, Signal is much better, but if you require it, you don't have to use the Play Store).
On the GrapheneOS forum you will see a lot of bad opinions about F-Droid, for example this:
> It doesn't matter that the app is trustworthy, because F-Droid are extremely incompetent with security and the apps you install from F-Droid are signed by F-Droid rather than the developer.
> If the app is only available on F-Droid / third party F-Droid repo, use F-Droid Basic and use the third party repo rather than the main repo if available.
>
> If the app is available on Github then install the APK first from Github then auto-update it using Obtanium. Be sure to check the hash using AppVerifier which can be installed from Accrescent (available on the GrapheneOS app store).
By the way, while GrapheneOS recommends Accrescent, I don't use it anymore because they can't even add apps like CoMaps, while some of the apps they actually added are proprietary.
>the apps you install from F-Droid are signed by F-Droid rather than the developer.
That doesn't seem like a con if you take into account the context: F-droid is not shipping pre-build binaries from the developper, it asks for a buildable project from the developper.
If the source repo of the upstream dev are compromised, so will be hid own binaries anyway.
> [A]pps you install from F-Droid are signed by F-Droid rather than the developer.
Having recently gone through the F-Droid release process, I learned that this is not necessarily the case anymore.
F-Droid implements the reproducible builds concept. They re-build the developer's app, compare the resulting binary sans signature block, and if it matches they distribute the developer-signed binary instead of their re-built binary.
This is opt-in for developers so not all apps do it this way. I'd sure like to know how common this is, I wonder if there are any statistics.
F-Droid only uses reproducible builds for a tiny portion of apps, and there are still significant disadvantages. It depends on the app developers always complying with F-Droid's rules otherwise users are left without updates. F-Droid only checks that the build matches, they do not review/audit the apps and will not catch hidden malicious behavior or simply non-compliance with their rules. WireGuard's app deliberately broke F-Droid's rules by including a self-updater which was not noticed by F-Droid and shipped by F-Droid. WireGuard used this to start taking over updates for itself to migrate their users away from F-Droid. F-Droid eventually found out when the WireGuard developer brought it up many months later and couldn't do anything beyond dropping the app. It had taken over updates for itself already and F-Droid wasn't in the picture anymore.
The process adds a significant delay for updates but it does not actually protect users from developers in any meaningful way. This real world example with WireGuard demonstrates that.
Private space is identical to work profile. In the past, private space didn't exist and people used work profile instead as a workaround, but now that's not needed.
Private Space has a superior approach to isolation and encryption matching user profiles. Work profiles have some compromises for historical reasons. Private Space should be preferred over a work profile and the only reason to use a work profile for your own local usage is to use both a work profile and Private Space at the same time. Once GrapheneOS has support for multiple Private Spaces within a user, the use case for work profiles will be limited to the intended Bring Your Own Device enterprise deployment purpose. The intended purpose of work profiles is companies not having to give their employees work phones but rather owning/controlling a specific profile on their device with some influence over the overall device via rules for lock method, etc.
It doesn't work for everything; one of the banks I'm forced to use checks for how it was installed, and Android for some incomprehensible reason is happy to report that to any application that asks (along with lots of other information like bootloader status and developer mode — you really have fewer rights to 'your' device than random applications).
After opening the application, it complains about being installed through an "insecure method", and bails. Reinstalling through Google Play magically fixes that.
These "security checks" are spreading like measles, so expect to see this sooner or later.
> one of the banks I'm forced to use checks for how it was installed, and Android for some incomprehensible reason is happy to report that to any application that asks
That's because apps that aren't published just on the Play Store but also on other stores or for direct sideloads (for users running Huawei for example which doesn't have Play Store) need to be able to detect the installation method to do updates on their own if there is no backing store.
The use case makes some amount of sense, but I think once an API becomes predominantly used for fingerprinting and the real use case becomes a side effect you should just nuke the API.
It's the responsible thing to do. Apple has done it a few times.
GrapheneOS managed to make Google play services into normal android services, without higher privileges that they have on other android systems.
I am personally more than okay with using the official, proprietary GP services from time to time if they abide by the same rules, especially that I can make these rules as strict as I want.
And even if you install Google play on your graphene phone, it is still more isolated by default. Add that to the concept of storage scopes and more permissions control (apps have to ask for access to the network) and you have a more secure platform.
Many apps claim to require Play Services, but all my (several) bank apps work perfectly on GrapheneOS. No notifications because they rely on Google, but that is more feature than bug in my books.
Signal brings its own notifications, so they work perfectly.
The only app which was broken to the point of unusability was Too Good To Go, which demands that you pick locations on a map which relies on Play Services; the manual city entry is broken.
I use Google Maps only in Firefox Focus, but I've heard that builds of Google Maps up to about a year or so ago didn't rely on Play Services, and with Aurora Store you can manually enter a build number to install.
Need the Maps data, the satellite picture, or StreetView? All these past years this WebView wrapper have been working like a charm https://f-droid.org/packages/us.spotco.maps
Uh GF uses TooGoodToGo, I might try if it works with MicroG and the companion app which appears at FDroid (can't recall now the name, but it appeared with Droidify and some repos). It must be a Play Services API placeholder out there too.
Install Droidify, enable the repos, and install "microG Services" and "microG Companion".
I hate that many banking apps refuse to run on non-Google OSes. I can see that my banking app doesn't even work on GrapheneOS based on the link given in a sibling comment. It makes absolutely no sense from a security perspective since I am still able to log in using the browser, and the web app has the exact same UI and authorization flows as the actual app.
It all seems like a security theater with the consequence that, ooops, we just vendor locked in all our customers to run a less secure OS by a company whose business it is to collect personal data and show ads that people don't want to see.
Banking apps are spyware, that's why they avoid open source OSes, not because they want to vendor-lock you. Smartphone data collected by a banking app is basically the most valuable in the world for advertisers, as they get the telemetry instantly crossed with a full(ish) picture of your spending habits and all the KYC identifiers too.
I'm always afraid of my phone getting stolen or losing it somewhere so I have a completely separate iPhone, which runs my banking apps. I keep that phone at home.
Depending on where you live, a burglary might be more common than a robbery. Why don't you just use the bank's website on your desktop computer (assuming you have a desktop computer)?
I'm in a similar position and I hate it. They somehow managed to convince themselves that if you issue tokens for 2FA within the mobile app it is still "two" factor authentication. Of course since you already have mobile app now, you can just use it directly (and there is no way to disbale that). So while webapp is 2FA, there is now a mobile app which is not. Good thinking.
Have a second profile with fewer restrictions for those apps you think you need but don't want to compromise security for. My second profile has one app, which is my banking app with all the dependencies it rudely requires for functionality
It depends what banking apps you use. Some are available. From my observation major banks in Poland work just fine. You can pay via NFC using the mBank app if you need to. Revolut also works fine. gPay just doesn't work however therefore you cannot pay with this via NFC.
I use my Garmin watch to pay for all things in physical stores anyway, so no need for NFC payments anyway.
Can you please clarify the Revolut part? Just to understand, you are saying that you are able to perform NFC payments via the Revolut app which you installed on your Graphene OS through the official Play Store? And you are based in Poland?
You shouldn't root Graphene, it breaks its security model and is certainly the reason why Revolut doesn't work on your phone. It works like a charm on mine.
What kind of issues did you have? I think it does require google play services (which can be installed easily).
I have used GOS on a pixel 6 for the past two years with no issues.
The phone finally died on me last weekend, so I'm in the market for a new pixel which will be getting GOS right away.
Can you please clarify the Revolut part? Just to understand, you are saying that you are able to perform NFC payments via the Revolut app which you installed on your Graphene OS through the official Play Store?
Can you please clarify the Revolut part? Just to understand, you are saying that you are able to perform NFC payments via the Revolut app which you installed on your Graphene OS through the official Play Store? Where are you based? (asking because I start having the doubt that it might be geo-dependent)
Happy long term user, great project. Here is a list of Open Source Apps, I use to replace Google stuff:
Aurora Store - Anonymized frontend for Playstore
F-Droid - Open Source App Store
Obtainium - App Store for other sources (e.g. github)
Organic Maps - Open Source navigation (not as good as proprietary ones though)
SherpaTTS - Text to speech for Organic Maps
PDF Doc Scanner - Little Trickster, Open Source document scanner
Binary Eye - Barcode reader
K9 Mail / FairMail - Mail client
LocalSend - Cross Platform File Transfer
Syncthing Fork - Catfriend1 Syncthing fork to sync files
VLC Media Player - media player
KOReader - ebook reader
Voice - Paul Woitaschek, local audiobook player
AudioBookShelf - Remote audiobook player
Immich - image backup
Fossify File Manager - file manager
Substreamer / DSub - Audio streamer for navidrome self hosted server
OpenCamera - Open Source camera app
I wish I had this list from the start... Hope it helps someone :-)
PassAndroid: to open apple/android wallet files (airplane/cinema tickets etc.)
Find My Device (FMD) on F-Droid: replacement for the google version, works via sms commands or a self-hosted app
AntennaPod: Podcast App
Breezy Weather: with multiple weather sources, great ui
How do push notifications and similar things work on GraphenOS? Do they work reliably out of the box on most apps, or did you have to set up MicroG/whatever GrapheneOS's equivalent is?
Push notifications work on GrapheneOS whether apps do it themselves, use UnifiedPush with the user's choice of provider or use FCM. UnifiedPush and FCM are a more efficient design where apps share a push connection. Unfortunately, many apps only support FCM and some support their own push as a fallback, but few support UnifiedPush. FCM works very well via sandboxed Google Play, which is an approach where Google apps can be installed as regular sandboxed apps with zero special access or privileges. Nothing FCM does actually requires special privileges and our compatibility layer makes it work without it.
GrapheneOS does not include sandboxed Google Play but rather includes an open source compatibility layer providing support for installing Google Play as regular sandboxed apps. They can't do or access anything more than other apps including the Google Play code running inside apps using Google Play which is the reason for choosing this design. It simply uses the same app sandbox and permission model which are both greatly improved by GrapheneOS for supporting running the rest of Google Play not bundled with apps using it.
Worth noting apps don't need Google Play services to use Google services and many Google libraries like Ads and Analytics work without it. FCM requires Google Play services but many of their libraries do. There are Lite variants of Ads and Analytics for keeping apps smaller which lose the ability work without Google Play services. The general reason for the design is they don't want to have huge apps and want to be able to update the clients for their services without app developers doing it and shipping an app update. FCM is one of the special cases requiring the central design for efficiency. UnifiedPush is an alternative with choice of implementation / provider.
> How do push notifications and similar things work on GraphenOS?
Some apps require Google's FCM for push notifications. You need to install Sandboxed Google Play services from the GrapheneOS App Store and grant them unrestricted battery access (so they can run in the background, which is required for maintaining a network connection to FCM and delivering notifications). https://grapheneos.org/faq#notifications
Other apps like Signal use their own background connections, for example WebSockets, to deliver push notifications, but keeping a connection open for each app consumes more battery life than just having one background network connection. Also, not every app supports this.
For Signal specifically, the GrapheneOS project recommends either using FCM via Sandboxed Google Play, or installing Molly (https://molly.im/), a fork of the Signal client for Android, which makes some changes to reduce battery consumption when using WebSocket-based notifications. It also allows you to use UnifiedPush (https://unifiedpush.org/) for notifications instead, but that requires an application called mollysocket (https://github.com/mollyim/mollysocket) running on a server.
Everything works out of the box, and it doesn't use a third party layer like MicroG. The difference is that Google's apps/services are not given admin privileges like they usually are, so you can selectively enable or disable things.
For example, installing an app on Google Play works like F-Droid. Once the download finishes, you have to open the Play store app to trigger a system dialog to accept the installation. On other Android devices, GPlay can install apps without your approval.
> Organic Maps - Open Source navigation (not as good as proprietary ones though)
Note that a community fork done by some core contributors was just spawned: CoMaps [1]
> K9 Mail / FairMail - Mail client
And now there's Thunderbird, which is branded version of K9 Mail IIUC (I don't know if there's any reason to switch from K9 Mail to Thunderbird for existing users)
Does the fork solve the issue with inputting addresses? Organic Maps will happily route to the correct street, but falls over when entering a standard format address (i.e. XXX Streetname Ave)
Absolutely. You can basically get almost the same experience as you would on a stock OS device, but with much better privacy. On the stock OS, Google apps get privileged access, so they can still access photos and your camera and all that, but what people don't realize is that their privileged access also includes things like usage data, hardware identifiers, etc. Using Google apps on GrapheneOS makes a lot of sense.
The only problems you might run into would be some features might require privileged access, things like Now Playing. Makes sense because normal apps cannot have unrestricted access to the microphone like that. Google Wallet works, but you cannot make payments because the app refuses to work on alternate OSes.
Besides that kind of stuff, though, I've used all sorts of Google apps without issues.
Over the years, Big Tech has given me reasons to trust them less and less. So I encourage you to be a rebel: cut Google out and live outside the system.
Last I heard, Google discontinued publishing device trees and driver binaries for Pixel devices with their recent changes to their stewardship of the AOSP [0]. Was it something definitive or are they merely delayed? If the practice is being discontinued, what would be the reason why? Doesn't publishing these artifacts create a business case for customer demand for the Pixel devices? Or is there some cost that outweighs the benefits? Is it maintainer overhead?
I didn't bring this up when it was a news story last month because there was a lot of cynicism in the thread, but I am genuinely curious. I am really grateful for both GrapheneOS and Google for creating a phone platform that Just Works for the essential stuff and that I can reasonably recommend to non-technical people!
Android 16 no longer provides device trees for Pixels as part of the Android Open Source Project. It's important to note it doesn't provide those for any other devices. There are no other OEMs providing similar AOSP support. A few OEMs publish more basic device trees for older Android versions. This was Pixels losing one of their advantages compared to non-Pixels but it was never one of our hardware requirements, which are listed at https://grapheneos.org/faq#future-devices. It isn't part of why Pixels are the only devices meeting our requirements. We're working with a major Android OEM to change that though, hopefully for 2026 or at least 2027.
GrapheneOS typically ports to new yearly Android releases in a couple days and tends to have it reach the Stable channel in under 2 weeks. We completed our initial port to Android 16 in a similar time period after the release on 2025-06-10. However, we then had to reimplement device support in a similar way to how we would support a non-Pixel device. Our initial production release based on Android 16 was published on June 30th. As usual, we had to spend around a week making a series of releases fixing regressions reported by users. It reached our Stable channel on July 8th.
Since our port to Android 16 took significantly longer than usual, we backported most of the Android 16 firmware, all of the kernel drivers and parts of the userspace device support to our now obsolete Android 15 QPR2 branch and did a few more releases based on Android 15 QPR2 where we were able to provide the full 2025-06-05 patch level which also turned out to be the full 2025-07-05 patch level due to no vulnerability fixes in the July 2025 Android Security Bulletin or Pixel Update Bulletin. This was an unusual approach and not generally a reasonable way of doing things. We were able to do it successfully.
It won't be nearly as much of an issue going forward since we dealt with building the new automation we needed. Our port to Android 16 QPR1, Android 16 QPR2, Android 16 QPR3, Android 17, etc. shouldn't be nearly as difficult and we should get back to our typical porting time for major releases.
It will start out being their regular phones with security and updates improved to meet the requirements of GrapheneOS. When we demonstrate there's a huge demand for it after the products launch, we can have more influence. Our focus would be adding some security features not available on Pixels. The current aim is preserving the security we get from Pixels, but the future goals are more ambitious.
The phone I am currently using has the following dimensions: 165.2 x 75.7 x 9.1 mm (6.50 x 2.98 x 0.36 in). I think it is a sweet spot for me. I would not go for larger than this.
Quite a lot of detail on this comment, thanks for that!
But I'm still left a bit confused about the future devices GraphaneOS will support:
Because you said discussion are being done with an OEM, will GraphaneOS switch from pixels to a different device?
You also said that not having the device tree won't be a major hurdle in building GraphaneOS for the future, does that mean we can expect the pixel 10 to have GraphaneOS or it's too early to know ?
Pixel 10 will be supported by GrapheneOS provided it continues to meet our requirements - we'll know when it's out. It'll definitely take us longer than it has before.
A collaboration with an OEM doesn't mean we'll stop providing existing or future Pixels if they continue to meet our requirements.
As you're working with the OEM, I hope you'll consider a model which will come with either an IPS screen or is compatible with a 3rd party IPS replacement.
I bought a Pixel 9 Pro Xl specifically to use with GrapheneOS. Unfortunately, its OLED and my eyes were incompatible. The PWM on the screen was terrible and I had to return it after some headaches.
Of course, none of that was the fault of GrapheneOS. I absolutely loved using it and think your project is vital.
> "As you're working with the OEM, I hope you'll consider a model which will come with either an IPS screen or is compatible with a 3rd party IPS replacement."
Ahaha, don't get your hopes up, friend. The possibility of an adequate, degoogled Android with picky requirements as GOS on good, ultramobile hardware (matte DCI-P3 IPS, 3.5 mm audio, USB-C 3.2 or better, dedicated, ideally quick-access mSD card slot, IP68 rating, good cameras, EMR pen compatibility, changeable battery, non-plastic case) is virtually nil. That would essentially be a modern hybrid between a Samsung XCover Pro 6 and one of the older Samsung Note phones, e. g. the Note 9. Days long gone... :(
I suppose this means that supporting future Pixel devices will be more difficult? If someone has the ear of anyone at Google, especially someone who works with Android, please share this cause with them!
Generic power-user here:
I am going to guess without the backing of Google going forcefully open-source, "niche" hardware such as Google's Tensor will lose their attractiveness.
However one must note also that for now not even Snapdragon fulfills GOS requirements. If/when that changes, Snapdragon devices may have more open-source community momentum than Google's Tensor. Plus all the economy of scale, etc..
In terms of security, Microtek is even more far behind Snapdragon.
Again, not an Android dev here, take the text above with a grain of salt, YMMV, etc..
It may be permanent and I think this was the official indirect response:
"AOSP needs a reference target that is flexible, configurable, and affordable — independent of any particular hardware, including those from Google." [0]
Emphasis on independent of any particular hardware.
Current speculation/inference suggests it is because of the antitrust case against them, preparing for the possibility that they may be divested of Android (or at least to decouple in meaningful ways [1]).
I heard unsubstantiated rumors that it was somehow antitrust-related. If they are selling off their device business (again), then it makes sense that the device drivers would not be part of AOSP...
Pixels are no longer the Android reference devices. An Android company ending up with the OS, Google Play and Google's OEM partners wouldn't need Pixels. That's a possible reason for the change. However, the simplest explanation is that they're continuing to take cost cutting to an extreme where it negatively impacts their long term revenue far more than the money it saves. A lot of Pixels were sold due to first class support for using other operating systems including it not voiding the warranty.
I have used LineageOS [0] for a few years on my old phone, and last year I got a Pixel 4 and I am using Graphene on it. Both systems work well and I am really glad they exist; Graphene gets extra points for its extremely easy installation process. Unfortunately it seems Graphene is already phasing out support for the Pixel 4 [1], so I'll have to switch back to Lineage at some point.
The only technical limitation I have encountered using these ROMs is related to GPS: my position is often lost and I need at least multiple minutes to gain it back (or sometimes it never comes back, depending on where I am). This is likely related to not using Google's location services, even though I have turned on all settings like using WiFi / bluetooth to improve the location accuracy. I tried every advice I found online, without luck. Somehow the issue is a bit worse on Graphene, as my position is lost every time I close the Maps app, but it may be related to the phone and not the OS.
>The only technical limitation I have encountered using these ROMs is related to GPS: my position is often lost and I need at least multiple minutes to gain it back (or sometimes it never comes back, depending on where I am). This is likely related to not using Google's location services, even though I have turned on all settings like using WiFi / bluetooth to improve the location accuracy. I tried every advice I found online, without luck. Somehow the issue is a bit worse on Graphene, as my position is lost every time I close the Maps app, but it may be related to the phone and not the OS.
Pixel 8 works amazingly with Graphene's new network location feature. Position fixes are SO MUCH FASTER. It is truly a gamechanger. First it was Wi-Fi only, but they just released cellular location as well. They provide a proxy to Apple's location services.
>>The only technical limitation I have encountered using these ROMs is related to GPS: my position is often lost
> Graphene's new network location feature
I believe it uses https://beacondb.net/, which is starting to have fairly decent coverage, at least in large parts of Europe. You can contribute to BeaconDB even if you have an ordinary Google phone by installing https://github.com/mjaakko/NeoStumbler.
I use LineageOS myself (because Graphene no longer supports my Pixel 5), and unfortunately it doesn't do network location out of the box. You can get network location on LineageOS by installing MicroG, but it's currently somewhat flaky.
We use Apple's location service, not beaconDB. We want to eventually make it so that it all happens offline, without any online service being used for it.
The main missing feature is password under duress that would open a different “user”. So even if you’re forced to give away your password they won’t get to the real account (some hidden profile or similar).
At least hidden profiles would be good enough for basic protection.
GrapheneOS community manager here. The problem with something like this is that it cannot be reasonably hidden when it would be exposed by someone using basic tools. Our Duress PIN/Password feature doesn't make any attempts to mask itself, precisely because we think doing that only gives people a false sense of security.
We think there's a good chance a motivated adversary is going to be familiar with GrapheneOS and its features, and the more mainstream it becomes, the more this can mean "your abusive significant other" rather than someone at the border.
The moment people know this feature exists, it can become dangerous even if you don't use it. You can be threatened to unlock, and even if you do, the adversary can choose to not believe you since they can think you're just hiding it. That puts you in a dangerous situation where they think you can provide something that's literally not there.
It's a very difficult problem to solve, and we don't think that proposal can solve it.
I hate to say this but I don't foresee Graphene being "mainstream". Most users will stick to the stock ROM. The most "mainstream" custom ROM Lineage is only installed on 0.04% of Android devices as of 2023 [1]. Even if Graphene appears in some mainstream news, I highly doubt any ordinary person can recognize it when they see one.
If the threat model is hiding from random people, I think a hidden profile works very well.
Now let's talk about motivated adversary as you put it. Hidden profile and wiping are not either-or, they can coexist. If one is really targeted by a motivated adversary, it should be apparent in most cases, and the targeted person can choose to enter the wiping PIN instead of the secondary profile PIN.
Now if one is targeted by a really motivated and threatening adversary, I don't think wiping PIN is any better than secondary profile PIN. The moment one chooses to wipe the phone, the adversary could be triggered by the action and harm the victim anyway.
GrapheneOS isn't a project that plans to be an aftermarket OS forever. In fact, we're currently working with an OEM to have their devices have official GrapheneOS support. This can mean devices being sold with GrapheneOS without someone even having to install it.
We're of the opinion that there's a growing portion of the population that is becoming more security and privacy conscious, and that's reflected in our userbase, which has been growing consistently over the last few years.
We're not saying we're going to have iPhone's marketshare, but we're constantly growing.
>Now if one is targeted by a really motivated and threatening adversary, I don't think wiping PIN is any better than secondary profile PIN. The moment one chooses to wipe the phone, the adversary could be triggered by the action and harm the victim anyway.
Yes, but at that point, the data is irreversibly rendered inaccessible. There are situations where the data itself is the most important factor, and where the owner of the device being hurt doesn't benefit the adversary now that the data is gone. Of course, as with everything, it depends on one's situation, but the duress PIN feature doesn't involve trickery. It's a way to reliably and quickly do a very specific thing.
> In fact, we're currently working with an OEM to have their devices have official GrapheneOS support
Oh god, yes. Please! I can't wait to leave the walled fruit garden, but can't tolerate Google sniffing everything I do or do not do on my phone either.
PS. I just hope it's an OEM that sells devices to a lot of countries including developing ones and not something like Fairphone.
> we're currently working with an OEM to have their devices have official GrapheneOS support.
It's a long shot, but please see if you can get this vendor to include an EMS stylus like the Samsung Note devices and S Ultra devices. That is what is keeping me on Samsung, and I will be one of their first customers if they have an integrated EMS pen.
I think it is all about audience. There is no one-size-fit-all. Different audience have different threat models and different requirements.
For a corporate using an OS in work phones. The threat model is state/corp-sponsored actors. Trade secret leak is unacceptable. When in doubt, data should be wiped. Now wiping PIN makes total sense and is the only sensible option.
An ordinary person, on the other hand, often deals with non tech-savvy ordinary people. The threat model is different. Most likely plausible deniability is enough. The threat level is low. Those users may accept to trade some data security for a more friendly feature.
The ultimate question is whether Graphene envisions itself an opinionated OS that always follows the "best practice" or a generic OS that allows users to define their own threat models.
These are ridiculous scenarios to try and optimize for. A smartphone feature isn't going to save someone from an abusive spouse or a serial killer, and if it does, it'll be an exceptional situation.
There was a youtuber who got kidnapped in Haiti a while back, and his kidnappers demanded to search the photo gallery on his phone for something. So what he did was delete the pictures, but not empty the trash, hoping they wouldn't know about that feature. They didnt, and he got away with it. Did Apple envision a kidnapping scenario when they were designing that feature? Probably not. Is there a design lesson that can be taken from that situation? Also probably not, because it just as easily could have gone the other way.
Tbh I’d say 99% of the criminals won’t know about this.
Let’s say someone have you at gunpoint, you can just give your mains profile pass.
If they don’t even know there is a secret profile you’re good to go.
You’re right, they might assume you’re hiding, but I’d say 99% won’t know what’s even graphene and from those who know I’d say they might force you and you can have 3 sets of bank accounts:
Main profile: 100
Secondary: 1000
Terriary: $$$
Also if you hide all traces of grapheneos would be safer too. Nobody even knows is graphene, so they can’t even check what features you have. Again we are talking about 99% of the criminals, not the tech savvy 1%.
I’d prefer plausible deniability like Vera crypt than what we have now.
You can argue most bad people won't know about it - but I would say we can't really know.
I think the main problem is that people can be affected that aren't even using it, which is why it is such a big problem. You can't really hide it's GrapheneOS either, even just by virtue of the features available on the device, you'll be able to deduce what it is.
I understand the idea behind it but it simply isn't realistic to provide and can put people in danger - the very thing it's meant to prevent.
But also in your case criminals can threaten you to give access to bank accounts you don’t have.
When I say hide, again for 99% of the people. Splash screen, setting spoofing. Sometimes good enough is better than perfect.
And even if the attacker can see the other profile you can just say was your friend’s profile and it’s lost.
Or better, not sure if possible: export the profile in a file like veracrypt. Then when you need the profile import from this file and would restore the secret profile.
There are certain threat/risk models where having multiple profiles might be helpful (non-forensic examination by an offical at a securtiy screening kinda scenario). But you're right, it's nuanced, requires know-how by the user, and possibly a foot-gun for some caught unawares. NOT an easy problem to solve. Personally, as a user, I'd like the ability to be able to choose that option in the instances where I needed it, but it's likey a TON of work for a very small actual user community who needs it.
I think this feature nowadays would be mostly for the border control checks, especially in the US. Basically to avoid being sent back over a JD Vance meme found at a glance, as opposed to actually being held hostage.
I remember a conversation with a political activist refugee. They were in a group of people who got checked at the border, and were asked to unlock their laptops. The border security personnel then proceeded to do a short inspection of the visible systems. They all used Veracrypt's Hidden Operating System functionality, and while it would be trivially detectable, the border security did not, so they got through without problems. If they had refused to "unlock", or used a duress passphrase that wiped the system without presenting a dummy version, they would have been held, possibly for a very long time, and definitely not allowed to exit.
Moral of the story: Different contexts allow for different solutions. It is a sign of false privilege to make assumptions, and not let the user decide. An argument can be made in terms of priority of implementation, but not in terms of "pointlessness". The often used argument of "false security" can be addressed by warnings; yes, some people may not understand the implications, but you do not need to make their own (bad/good) choices for them; that's paternalism, not care.
In the real world, where thanks to my political work I am in contact with many people who had to endure real-world security checks, police raids, investigations, and so on, in all the cases no proper (imaginary) forensic analysis was performed. People make mistakes and remain uneducated -- on both sides. The "But NSA!" argument brought forward typically by white techbros kills a lot of useful technology before it even exists, which is unfortunate for those that would actually benefit from it, and when asked would tell you so. It's also not either/or in reality: In many situations, it will buy you time (while e.g. your lawyer may try to get you and your devices out of the situation), and even if they find out you were trying to fool them, they may give you another chance, and then you can still opt for the wipe code. It makes a huge psychological difference to have multiple options and feel in control.
This hyperbole is extreme, and unnecessary. If your life depends on the ability to simulate a fake user on a phone, there are more significant problems than a lack of operating system features, and a general failure to defend in depth.
This is a fully general argument against any single thing your life might depend on: seat belts, defibrillators, bulletproof vests, etc.
If the only thing protecting you from getting shot to death is a bulletproof vest, clearly a lot has already gone very wrong, and you're likely to die today anyway. But that kind of thinking is exactly what leads to a failure to defend in depth.
GrapheneOS Discussion Forum: "This site is best viewed in a modern browser with JavaScript enabled. "
Security my ass ...
To "GrapheneOS community manager" - please fix this. Where is .onion site?
Security doesn't mean you have to go feed the cows and leave behind everything.
In fact, a core aspect of security is having access to a feature in the very first place.
A forum, being hosted on the web has absolutely no reason to stay away from the de facto scripting language of the platform. What would be your threat model for that forum? A zero day that would break the whole world?
It is possible to view the forum without JavaScript being enabled, but not sign in and post. We use Flarum for our forum, and that's a limitation of the platform.
My only problem with Graphene is the ridiculous low number of supported devices, i know I know, security reasons and so on. But I would accept an lower security hardened version but at least have Graphene instead of Google's junk
However, we're currently working with another OEM and are hoping to have a device of theirs meet our requirements that can be launched in 2026 or 2027. Nothing set in stone, but we're optimistic thus far.
Extremely happy GrapheneOS user here. Thank you so much for the work you and your colleagues do. Speaking for myself, the adoption of a mobile communication and computing choice that both put me in control of what information I interact with and respects my agency enough to present me with the hard choices about what I do and don't want for myself has been a life-altering upgrade in something midway between "peace of mind" and "outright mental health".
Much like you don't hear the sound of a busy city until you go somewhere truly quiet, you don't remember owning your own brain until you evict all of the entities who have been living rent free in it.
Keep doing the great work you're doing: it's making people's lives better in dramatically more significant ways than most software.
I can understand the GOS' rationale in choosing only the most secure phones. However, I'm more concerned about privacy, and not so much about security. It'd be great to have something like a "GOS-Lite" which accepts some security compromises in order to bring privacy to more people. (And yes, I understand that lower security means less privacy from targeted attacks but even GOS depends on OEM blobs, right?)
If it's a repairable phone like the Fairphone, that would be fantastic. Otherwise, I'm already very satisfied with what you offer. Thanks for you work.
Fairphone do not meet our requirements and haven't really been trending towards meeting them generation-by-generation. It doesn't seem to be something that interests them.
The unfortunate thing is that they make security promises which aren't upheld in practice (such as shipping security updates on time), so it doesn't inspire confidence as an OEM you could trust to properly support a device for multiple years.
We're hoping that there will be people who will enjoy a device from the OEM we're in talks with - we know that there are many people who for various reasons don't want a device from Google, so this will at least offer an option for people who want to use GrapheneOS on a non-Google device.
It's important to note that these "8 years" aren't actually that in practice due to the delays. The latest generations of Pixels (starting with the 8th) have 7 years of actual security updates, which is one year less, but is proper support. Hopefully the industry trends towards that as a whole - buying devices that only get 2-3 years of updates should be a thing of the past.
Isn't that related to how expensive it is to get licenses from MTK and Qualcomm for updates? Given that Pixels run on their "own" chip, driver support is probably much easier.
Fairphone devices have 1-2 month delays for partial security patches. They have a year or more of delays for new major releases. Their recent Fairphone 5 uses the Linux 5.4 LTS branch going end-of-life in December 2025 with no plan to port to a new LTS branch. Their past devices use end-of-life Linux kernel branches. They do not provide the expected security patches even shortly after release. They aren't doing the bare minimum and aren't even compliant with recent EU regulations for device updates.
Google provided resources for the Linux kernel to extent LTS support for 6 years for their 5 year guarantee with the Pixel 6. It ended up not being needed since Pixels began moving to newer Linux LTS branches. The official Linux kernel LTS support is back down to 2 years. The 6 years was meant to benefit all Android devices but it proved to be too difficult to do well and it makes more sense to invest a far smaller amount of resources moving to new LTS branches.
Fairphone presents providing an Android OS release 3 years after it was released as providing 3 more years of extra support compared to an OEM releasing it in the month it was launched as their final update. That doesn't make sense.
They've repeatedly had blatant security flaws such as using publicly available private keys for signing the OS on the Fairphone 4. These issues are downplayed rather than being acknowledged.
There are important security features missing, but the main issues are the lack of proper updates and their approach to security flaws being reported and discussed.
Many Android OEMs are a better fit for a partnership with us and we're working with one.
I had to Google this. Is this like a fine-grained version of mprotect, i.e. associated permissions with each tag? Or are you only interested in the memory safety benefits? Regardless, why target requirements that even most desktop computers don't meet?
> Hardware memory tagging is going to provide a massive increase to protection against remote exploitation for GrapheneOS users. It's the biggest security feature we'll be shipping since we started in 2014.
> Is this like a fine-grained version of mprotect, i.e. associated permissions with each tag?
It provides the ability to tag 16 byte granules of memory with 4-bit tags where only pointers with the correct tag can access the memory. This provides an approximation of memory safety very useful for security.
As an example of how it gets used, our implementation of the system allocators via hardened_malloc tags each allocation with a randomly generated tag excluding the adjacent random tag values and previous random tag value for the slot. It has the standard setup of a single statically reserved tag (zero) used for free memory but adds 3 more dynamic exclusions. This provides deterministic detection of small overflows, linear overflows, many forms of use-after-free and fallback to probabilistic detection of other spatial (bounds) or temporal (use-after-free) memory safety issues. We use a lightly modified variant of the standard MTE integration for PartitionAlloc in our Vanadium browser, but we plan to improve it to match hardened_malloc. We use the standard Linux kernel implementation for the internal Linux kernel allocators which needs a lot of improvement.
> why target requirements that even most desktop computers don't meet?
Desktop computers are far less secure than an iPhone or a Pixel with the stock OS. GrapheneOS exists to provide a higher level of privacy and security than those. GrapheneOS is primarily aimed at mobile devices which are almost entirely 64-bit ARM. Hardware memory tagging (MTE) is a standard ARMv8.5 / ARMv9 feature provided by every standard ARMv9 Cortex core. MTE is only missing with custom CPU cores or cache while cutting this corner.
Pixels are not the only devices providing MTE. Exynos and MediaTek have provided it and Snapdragon should be providing MTE starting at the end of this year. The only reason Snapdragon is late to the party is due to their custom cores/cache.
We're currently working with a major Android OEM towards multiple of their future devices meeting all of our requirements and providing official GrapheneOS support. They view all of our officially listed requirements as completely reasonable and a target they can meet for their next generation of devices.
The purpose of GrapheneOS is providing a high level of privacy and security, not making security less bad for devices people already have. Hardware and firmware security matters quite a lot and software security depends heavily on hardware-based security features including MTE. Nearly all GrapheneOS users buy a device to use GrapheneOS and that would still be the case if we supported several other devices. The vast majority of Android devices lack proper security patches for drivers/firmware, are missing important hardware-based security features and don't provide serious support for using another OS where the security features can be kept intact. Samsung's flagships are closest to meeting our requirements after Pixels but do not allow another OS to use verified boot, important secure element features and more. Samsung permanently cripples their devices if they're unlocked and voids the warranty, unlike Pixels.
The reason we're working with an Android OEM is because existing non-Pixel devices don't provide a base we can use to provide what GrapheneOS offers. It would be missing huge parts of the core features elsewhere and would be worse in significant ways than the stock OS. It would go against what we're trying to achieve to have people buy devices we can't properly secure. Long term support for drivers and firmware is also important because people use devices more than 3 years from launch in practice. Pixels get 7 years of proper support from launch, which is unique. A couple OEMs market their devices as having similarly long support but the updates are significantly delayed and far less complete.
We've had numerous opportunities to work with OEMs where they weren't able to provide our requirements. We simply aren't interested in having a far less secure device with GrapheneOS as the stock OS. We expect our requirements to be met, and we think the OEM we're currently working with is fully capable of providing what we need. It will hopefully be available in 2026 or 2027. The initial goal is not doing better than Pixels, just providing a competitive alternative for people who want to use GrapheneOS on another brand of device.
What's ridiculous about it ? There are now 4-5 gens of Pixels with their major/minor bumps too (A series, pro, etc.). There's enough variety at different price points for everyone there.
The other devices don't meet the criteria. Be happy that Pixels are supported, for Google seems to closing down Pixel OS too, making this whole effort rather difficult.
the CONSUMER criteria is "we want better independent security ON DEVICES WE ALREADY OWN"
complaints like in this thread are symptoms of unfullfilled demand - and they can't be solved by saying "oh gosh, what a stupid demand that doesn't agree with our supply"
I actually like Graphene's focus in Pixel. It is available in a lot of countries unlike Fairphone - via Pixel of course.
So Graphene is actually not limited to the developed/western world. As for not supporting other devices, I believe the reason could be the team size and the fact that the fragmented Android world is known for unique shenanigans of every OEM. Besides Google's update/upgrade cycle is another reason it is an appropriate choice.
Meh. Not all people have the strictest security (and privacy!) requirements. While it is admirable that GOS strives for perfection, I would be more than happy with a less secure, but repairable phone, such as Fairphone.
So just give me that alarm system for my tent, please. It will do fine for my case.
We don't really strive for perfection. Pixels aren't really perfect and there are numerous suggestions we could make today for Pixels to drastically improve their hardware. Our requirements are in some way below what even Pixels provide today.
Our requirements are not at all exotic or outlandish, the fact that most OEMs don't meet them says more about how far behind most OEMs are, rather than our standards being unrealistic. We've also been told that they're not unrealistic in practice from numerous OEMs who want to build a device that meets our requirements.
It is also important to note for Pixels specifically that since the 8th gen Pixels, they receive 7 years of support. Additionally, they partner with iFixIt to provide official replacement parts for the duration of the device's life. I'd say that's pretty sustainable, especially when you consider that the Fairphone doesn't actually provide proper support for the amount of years they claim, since they have consistent delays in providing patches.
GrapheneOS community manager here. Google did make it harder to support Pixels, but we're still doing it and plan to continue supporting new Pixels provided they keep meeting our requirements.
At the same time, we're in communication with an OEM to have some of their devices have official GrapheneOS support, so we're moving towards redundancy.
CalyxOS downgrades security compared to the Android Open Source Project, often falls significantly behind on standard Android privacy and security patches as is the case right now (they still haven't ported to Android 16 which is required to have the latest patches) and doesn't provide similar privacy or security features.
Features like Contact Scopes, Storage Scopes and our Sensors permission toggle are some of the privacy features includes in GrapheneOS.
Privacy necessitates security. The security provided by GrapheneOS is in order to be able to protect privacy.
According to the link you provided, it does seem to be ahead of stock Android (assuming AOSP) and LineageOS, disproving your point that it's falling behind.
The point of the OP is not that it would be better than your solution anyway; rather, if you have a device unsupported by GrapheneOS, Calyx would be better than nothing.
Depends on your threat model. If Google, low-effort scam apps or being profiled by apps are your only adversary, then that's true. If random threats on Internet or APTs pwning your phone, or being forensic-proof are part of your threat model, then Calyx is strictly worse than stock.
I am a long time GrapheneOS user, amazing project. One thing that is not clear to me is the support for NFC payments. Las time I checked, NFC payments on Graohene didn't work at all, but I am reading on this thread that some users do manage to pay via NFC? Did Iget this right? Mind explaining how?
I do not use banking apps (I only use banks that allow me to log in via browser using a 2FA which is not a proprietary app, like a FIDO key or other physical dongle), but do I get it right that Revolut would allow me to pay via NFC in this case? Is this something geo-dependent?
The issue isn't with NFC. It's passing the Play Integrity check that app developers optionally can use to prevent devices that don't pass the check from running their app, or remove parts of its functionality. IIRC I don't think any custom ROM's can pass the check. So you might be able to pay via NFC with a banking app if they don't implement the Play Integrity API. For Graphene's thoughts on the matter (2024):
GrapheneOS community manager here: They weren't using Play integrity and we were able to work around what they were doing, so Revolut should work again. They can decide to use Play Integrity in the future, though.
Revolut currently works fine on GrapheneOS. If they decide to adopt Play integrity, it won't work unless they whitelist GrapheneOS, which banks have started doing.
- Adding your card to Google Wallet.
- Using a banking app which actually implements payments via NFC.
Many banks used to implement the latter, but dropped it in favour of "just use Google Wallet". In the Netherlands, it seems to be all of them. This varies a lot per region.
I believe that the "just use Google Wallet" banks are the ones that don't work.
Also (as others have mentioned): many banks perform integrity checks, to ensure that you're using a software chain signed by Google.
If I need to buy a phone made by Google to get away from Google, I'm just not doing it. /e/ doesn't support my current smartphone, either, and postmarketOS is not functional. At this rate, I think we're better off going back to dumbphones.
Even if you aren't concerned about the possibility of "backdoored hardware" (and I am not, for one), I'm still sympathetic to the argument that giving money to Google is morally wrong because it provides financial support for their data-harvesting business model (though since you use GrapheneOS, they'll only be able to use it to harvest other users' data, of course, not yours). Buying a used Pixel doesn't support Google financially, so perhaps that's more ethical.
Thank you. I have the same worry. I'm not a developer, how could one tell there isn't some built in backdoor in the hardware? There was another HN posting on Graphene and asked the same question there with no answer.
I am (very slowly) migrating from iOS to GrapheneOS, for the same reasons as OP (privacy, Apple's increasingly user-hostile and developer-exploitative policies).
Apart from migrations concerns, which are not GrapheneOS' fault, the main shortcoming I see is the lack of proper backup/restore, e.g. when switching phones. There is Seedvault, but I've found it unreliable.
> ""will never again be closely tied to any particular sponsor or company"". Work on GrapheneOS is supported by a Canada-based foundation created in 2023; there appears to be almost no public information available regarding this organization, though.
A question for strcat / other Graphene developers:
Can you clarify what can one expect from legacy extended support. Will old devices get any more updates? how long, how often, is it just security patches etc..
Not a dev, but legacy extended support means that there are no more feature updates, i.e., no new Android versions or QPRs, only AOSP security backports.
Obviously there aren't any firmware patches either, as these devices are unsupported by the manufacturer, who is responsible for delivering any changes to the firmware.
Does anybody else here see as problematic that this OS supports mostly Pixel, a Google phone?
Over and again people on HN make the following argument: "Google is a company that makes most of its revenue from ads and surveillance. Therefore, you should always assume that Google is spying on you". But somehow when it comes to Pixel people give it a pass?
Prediction: If Pixel isn't already hardwired to phone home and report on your activities, it will slowly become so over time, as Google realizes its interest. You know, as it happened with Android, Chrome, and everything else that Google touches.
I think it's perfectly valid to consider this as problematic (the GrapheneOS team certainly seems to think this is not ideal, for example). However - somewhat counter-intuitively - it's also valid to consider Pixels as among the most secure and most appropriate Android phones for something like GrapheneOS.
Your prediction is about a hardware product, and your examples are both software products (one is a browser and another is a mobile OS, both of which are platforms for running other software, and thus extremely well-suited to the task of reporting user data back to Google).
I'm not an expert, but baking telemetry into the hardware (or at least the kind of telemetry that I assume Google is interested in) seems like skipping a few levels of abstraction, and thus more trouble than it's worth.
> baking telemetry into the hardware (or at least the kind of telemetry that I assume Google is interested in) seems like skipping a few levels of abstraction, and thus more trouble than it's worth.
This isn't really a practical way of doing it. Google Play and Google Play Services having privileged access is more than sufficient.
This is just conspiratorial fearmongering based on vibes. If pixels somehow phoned home on a hardware level, do you think we wouldn't be able to tell? Do you think we wouldn't see it in our network logs?
GrapheneOS supports pixels because they are currently the only devices that fulfill their list of requirements, like an actually usable secure element, hardware memory tagging, etc.
They have said and continue to reiterate that they would support other devices that fulfill their requirements and seem to be currently looking into working with OEMs to move away from pixels in the long term.
Just saying "you claim to degoogle phones yet the phone you use is a GOOGLE pixel, suspicious" is baseless nonsense.
> If pixels somehow phoned home on a hardware level, do you think we wouldn't be able to tell?
Yes.
> Do you think we wouldn't see it in our network logs?
If it's done on the baseband processor, no.
I believe grapheneos has some sort of band band processor isolation, but I'm not sure exactly how it works.
But yes - your phone has a separate SOC, with its own operating system you can't access, which communicates with cellular networks. We don't know what, exactly, it's used for or what, exactly, is being transmitted. We do know it's used for location tracking because this is utilized by law enforcement somewhat regularly. But cellular triangulation isn't too accurate, not like precise location services.
Graphene is a fantastic operating system for Pixel devices. Simple, reliable and with plenty of security and privacy features to make you feel warm and fuzzy. System updates are automatic, actual phone functionality is flawless, perhaps the only complaint to be had is the quality of camera, which probably lacks proprietary drivers. Signal works fairly well - even without abusive Google Services installed, making this a perfect daily mobile driver. Much gratitude to the developers of this project.
GrapheneOS does not degrade the camera quality at all. The quality will depend on the app being used. If you use Pixel Camera on GrapheneOS, you'd be getting the experience you'd get on stock OS using that same app. Similar for our built-in camera app.
Perhaps a newbie question, but since there's a lot of Graphene users here I thought it'd be best to get a human answer.
I have an old Pixel 5 which I stopped using because Google dropped Google Pay (tap to pay) on it. I moved to a new device (Pixel 9) for daily usage but still have the 5 laying around (due to low resale value).
At the time I moved, Pixel 5 was about 1.5 years (November 2023) beyond Android security updates. I still love the form factor (more than the bigger 9 I use now) and it has much more life left in it. I'd quite like to use this as a backup device for basic utility (camera, phone, SMS, basic read-only web use) and to take with me for runs and travelling.
Would installing GrapheneOS on this device likely make it more secure? Do Graphene releases work the same on all devices, or is it sort of device-by-device basis?
Yes it will make it more secure (and faster!), but it is already receiving only bare EOL updates, but will definitely give it some life extension. See: https://grapheneos.org/faq#supported-devices
You won't get the full set of security measures (those require newer Google Tensor chipsets with ARM Memory Tagging Extensions, so Pixel 8 and later), but it's still going to be far more secure than any Android or even iPhone.
Regarding NFC payments, the apps themselves refuse to run on non-vanilla OSes due to spurious security concerns and Google's maneuvers behind the scenes, but there are reports that Curve Pay works, at least in the UK.
That shouldn't be much of an issue. I didn't plan on NFC payments going forward. If I use the web minimally and toggle the internet off when not in use, that should be pretty secure, right?
I'll give it an install tonight. I'm curious to play around with it anyway and if I make minimal use of it, it should be pretty secure by it's use case.
Yes definitely more secure than stock, it is actually staggering to compare some of the features like ability to give apps access to only a selected set of contacts/files which as far as i know is still not on base android. whatsapp for example gets ALL of your address book or nothing (limiting usability) on other OS but on Graphene i can give it just 10 whatsapp-only contacts. I dont know how long the 5 will keep getting updates but for all I know it will be some years. the installation process is surprisingly the easiest of any mobile os I have ever encountered, you will be impressed!
It's interesting that the only devices complying with the security requirements are Google's.
I wonder if Google actually has an internal version of Android that's more security-focussed. Given that critical engineers' personal devices being hacked should be a security threat that's on Google's radar, it's possible.
As a large company, they are probably targeted through their devices and since they have the means, it does make sense that the Pixel devices have high security standards compared to other OEMs.
Why do you think that's interesting? Google is highly respected for its security practices. Do you think Apple engineers use some special hardened iOS?
I have been using GrapheneOS en my pixel for almost a year and quite satisfied.
The docs for compilation are neat so I'm running my own build with my own signatures and my own repository of their AppStore for my third party apps that I also build from source.
I run only those apps on the main profile and then keep a private space (set to autokill on lock) for proprietary apps that require Play Services.
I'd install Graphene OS in a heartbeat on my Pixel if they'd add support for Google call screening and feature like Hold for me. Thise features are why I bought my pixel and it's too much of an inconvenience to go without them now. Spam calls have went down significantly and has saved me a lot of time.
Been using it for the past two years and supporting the project. I personally love it but you do have to tinker a bit once in a while so I would hesitate to put it in the hands of my parents (though I bought them pixel just in case). Google Pay not working is mildly annoying (hoping to get PayPal or Curve eventually). Android Auto works but I didnt yet try to make voice commands work. Some app behave weird if you block access to the sensors (though it is nice to be able to do it). Sandboxed google play works great for the most part.
My workaround for using both NFC payments and Graphene OS is wearing a Google Pixel Watch (1). All other Google Wallet features besides NFC payments should work.
Sadly that solution does not work everywhere. In a lot of countries, Google Pay cards are added by the bank's app and it's on the bank to support rolling out cards on WearOS as well. A lot of banks in my country only support putting a card in Wallet on phones, but not WearOS watches (not sure if it is laziness on their part or whether security of WearOS watches is not deemed acceptable in general due to the lack of secure elements, shorter/no PINs, etc.).
True privacy is such a rare commodity these days. It’s a breath of fresh forest air to enter an OS unwatched, allowing your mind to be free.
Not to get too deep, but contemporary philosophy posits that our phones have become extensions of our brains (not only theoretically, but literally! See e.g. Andy Clark and David Chalmers, “The Extended Mind,” 1998). Our devices have access to profound parts of our lives— our habits, friends, desires, notes, thoughts… With something this fundamental, it’s vital to have privacy.
Thank you, Graphene team, for all the hard work you do.
I'd like to switch phones soonish and was looking at the fairphone 6 with /e/OS but feel deterred by its mid range specs which would probably limit its longevity. I would like to get away from google.
Is waiting for the new pixel and then putting grapheneOS on it a good way forward? Seems weird to pick a google device to get away from that company.
Has anyone else done the same?
Alternatively, there is the iPhone but I do like fdroid and the more open nature of android.
> I'd like to switch phones soonish and was looking at the fairphone 6 with /e/OS but feel deterred by its mid range specs which would probably limit its longevity. I would like to get away from google.
> Is waiting for the new pixel and then putting grapheneOS on it a good way forward? Seems weird to pick a google device to get away from that company.
> Has anyone else done the same?
I did end up going for a Pixel + GOS.
Although it is conterintuitive to use a Google device to get away from Google, according to GOS developers themselves, the Pixel series were the only devices that met their strict requirements for security.
From personal experience, been using it for almost 3 years now, and it gives you 95% of the benefits of Android while giving you back control over your phone, and being generally more secure.
Just stay out of the radar of the leadership, they can be a bit abrasive, for the lack of a better expression.
Is the camera with GrapheneOS as good as the stock android one? I get to use my wife's iPhone camera sometimes and it frequently shocks me how good and responsive it is. But I'm coming from a OnePlus 8 Pro, which never had a great camera in the first place.
I suck at taking pictures. It's definitely good enough, but worst case you can install the stock Google Camera app and disable network permission to limit snooping.
I think the Pixel Tablet was a matter of a week or two.
There seems to be two challenges though that popped their nasty head lately.
Some developer being temporarily unaivalable due to personal issue, and something about Android Open Source Project (GOS is built upon it, to put it simply) not necessarily support upcoming Pixels.
But the team seems resilient and motiviated to keep the project going.
I was tempted to use this but when I looked into the team behind it there seemed to be some issues as exposed by Louis Rossman here: https://youtu.be/Dl1x1Dy-ej4.
Instead, I installed CalyxOS and have been using it over a year now and I'm very happy with it. Check it out.
Hi there. GrapheneOS community manager here.
It's a weird video to bring up without any context. Louis Rossmann made that video and leaked private conversations that were had fairly soon after the person in question was repeatedly swatted by someone who has a fan of the person Rossmann was voicing support for.
Unfortunately, Rossmann turned out to be very dishonest, which in retrospect makes sense, seeing as he has no issues with using Kiwi Farms. He's verified account there is named "larossmann". I suggest you look into it.
It's not just something he's done with GrapheneOS and the founder of the project. There are many videos, such as the one he did on Linus from Linus Tech Tips where he similarly misrepresented things and ascribed mental health labels on them.
Regarding CalyxOS, I would recommend people check out https://eylenburg.github.io/android_comparison.htm as a third-party comparison for various projects, including GrapheneOS and CalyxOS. They're not similar projects.
> Louis Rossmann made that video and leaked private conversations that were had fairly soon after the person in question was repeatedly swatted by someone who has a fan of the person Rossmann was voicing support for.
I am sure you have proof for such a justiciable acccussation? The perpetrator is in jail and you can link to the court proceedings for example? You are surely not just regurgitating another hallucination by the Graphene developer, right?
The swatting attacks are public record, and can be confirmed through Toronto police records.
> another hallucination by the Graphene developer
I'm going to assume that by you saying "another" you mean that there were hallucinations before this one.
What you are doing here is repeating baseless claims that they're crazy, which is complete nonsense. This is exactly the kind of problematic stuff that shows up on Kiwi Farms. Again, Rossmann has an account there and some of his videos seem to be made to appeal to Kiwi Farms users.
> The swatting attacks are public record, and can be confirmed through Toronto police records.
Which is not what I'm talking about. You claim you know who did it. Where is the proof?
Though I never doubted that the swatting attacks occurred, I am noticing now that you mention police reports without linking them. Let me guess, there is nothing online, no police press release, nothing?
> I'm going to assume that by you saying "another" you mean that there were hallucinations before this one.
Yes. Like the attacks he hallucinates from project like Calyx and from the Techlore Youtube channel, and the documented way he turned on Rossman. Always claiming there is proof he already provided for the evil machinations of the others, with references going to other claims of having provided proof before, with none to be found anywhere down that chain. That is pretty easy to categorize behaviour. I personally would not call him crazy (who the fuck is "they"?), that seems to be hurtful, but I am confident in seeing signs of a mental disorder there and stating that publicly.
> Again, Rossmann has an account there and some of his videos seem to be made to appeal to Kiwi Farms users.
Complete Bullshit. Provide links to the videos, otherwise that is another evidenceless attack and just confirms your pattern.
The above video refers to a video by Destiny (https://youtu.be/ba383Zux0Mo) where he spends a bunch of time defending Kiwi Farms. Rossmann making a video about it and joking about "lolcows" is what has contributed to people at Kiwi Farms worshipping him, and his fan starting a thread about Daniel there where people tell him to kill himself.
Stop defending this stuff and finding every opportunity you can to try and gaslight others - it's weird.
No. Nobody claimed to know the actual identity of the person.
> Like the attacks he hallucinates from project
They're not hallucinations.
> I am confident in seeing signs of a mental disorder there and stating that publicly.
Not a doctor, but is confident in their diagnosis of someone they don't actually know after watching some YouTube videos.
> Complete Bullshit.
I mean that these kinds of videos where he portrays people as crazy appeals to Kiwi Farmers. His verified account there, him participating there, and him making videos that do appeal to them all add up to me coming to the conclusion that they _SEEM_ to be made with the _intent_ to appeal to Kiwi Farms members.
It is genuinely very strange that you're relying on people simply not clicking the link you're providing.
The person who swatted Daniel spent days raiding our Matrix chat rooms, posting gore and CSAM. We know it was them who did it, because they bragged about it during their raids before we had made any public comments about it happening.
We don't know who the person is, and neither does the police. The details we have about what was said during the calls was provided to Daniel via the police, especially since it happened 3 times, not just once. Thankfully after the first time the responders were somewhat aware of what was happening so it wasn't as scary.
Disclaimer, I am a GrapheneOS user. I was introduced to GOS by Louis Rossmann initial 2 or 3 videos talking about giving them a FUTO grant, as well as praising GOS and showing how it easy it was to install, and how it gave back control to the user, and all the good things that GOS genuinely provides.
I have (unfortunately) followed this saga and went down the rabbit hole since the very beginning. To my understanding based on publicly available data, the key "evidence" put forward by GOS developer(s) / community manager would be:
1. Louis Rossmann leaving the now pinned comment "Informative but unfortunate" on TechLore's video on the leadership of GOS. They claim this is Rossmann showing support for Techlore and his community to (allegedly) harassed the (at the time) lead developer of GOS.
2. Louis Rossmann having KiwiFarm account. Yes, KW is a cesspit. However, all of Rossmann's message on the board mostly focus on either addressing misconceptions about himself, or promoting right to repair and similar topic. This can be easily checked, and at no point there is any public evidence of him supporting harassment toward the GOS developers.
3. Louis Rossmann being acquainted with leadership of other de-googling Android OSes (CalyxOS mainly I think) and also giving them a FUTO grant.
Essentially, "guilt by association". I know this because I have asked the community manager (goes by mbananasynergy on HN, and similar aliases on other platforms), and that is what they provided as "evidence" for Rossmann being guilty of harassing or promoting harassment against them (along with mentions of having 2 millions of USD worth of backing and ready to sue Rossmann, which has not materialized as far as know since ~1.5 years ago).
I want to preface by saying that GOS is really a good software, I have been using it for 2 or 3 years since then, and no complaints on that side.
My biggest gripe however, is indeed with the leadership and management of the community.
I created a new account instead of posting this with my main because the leadership is in my experience very abrasive, to say the least.
I have been banned without appeal from their Mastodon for leaving "thumbs up" smiley on : 1) messages suggesting the GOS devs to do an interview with Rossmann (as he did with other projects that received a FUTO grant) to further spread the word, or 2) messages suggesting to clear up the misunderstanding between the devs and Rossmann.
Any disagreement on their official narrative, or contrary opinion (even in good faith) leads to bans if they are in control of the platform, and accusations of collaborating with groups that harass the developers. Even here, anything contrary to that narrative will receive the usual wall of text describing the poster as sockpuppets, harassers directed by Rossmann, Techlore, CalyxOS, or any other projects GOS developers are beefing with.
I am disappointed by the situation, because I think GOS could have a larger presence and contribute to raising awareness about the importance of data security, but their leadership seems to be a considerable roadblock on that direction.
This is a very interesting summary indeed, however I think matters are simpler and noone needs to dive that deep.
Unfortunatelly, EVERYONE, from all parties, fire shots for the wrong reasons, which perverts the discussion.
When you say to people to not use GOS because the lead dev is paranoid or the community is hostile you are throwing out the baby with the bathwater. The value GOS brings is undisputable. The quirkiness of the leadership is also undisputable. Let's decouple the two. If you wish for the community to get better, become yourself the better contact point amd generally focus on suggestion on that matter. Don't say to people to not use arguably the most secure android rom!
I used to respect Rossmann a lot, but he fell in my eyes both for the LTT and the GOS incident. I have been watching LTT since a kid and I know that his has grown to be a jerk without looking at his private communications, but his competitors fired shots at him for the wrong reasons (honey case) and so did Rossmann, riding the wave.
If you want to criticize someone for being a jerk do it, but do it for the right reasons, don't muddy the waters by injecting other stuff in the discussion.
> When you say to people to not use GOS because the lead dev is paranoid or the community is hostile you are throwing out the baby with the bathwater. The value GOS brings is undisputable. The quirkiness of the leadership is also undisputable. Let's decouple the two. If you wish for the community to get better, become yourself the better contact point amd generally focus on suggestion on that matter. Don't say to people to not use arguably the most secure android rom!
It's one thing to separate the artist from the art, but I think that analogy does not apply when it comes to e.g. an operating system which essentially handles all of your private data.
If anything, not being able to separate the art from the artist is the exact reason why GOS exists, the artist being "Google" and all their controversial practices.
(Edit: or a simpler analogy, would you trust the food (art) of a cook (artist) that threatens to ruin your life ?)
The OOP is entitled to express his informed opinion and even provided what he based it upon.
As a user, I think that is important context when it comes to picking something as sensitive as an OS.
> I used to respect Rossmann a lot, but he fell in my eyes both for the LTT and the GOS incident. I have been watching LTT since a kid and I know that his has grown to be a jerk without looking at his private communications, but his competitors fired shots at him for the wrong reasons (honey case) and so did Rossmann, riding the wave.
I happen to have a similar background as far as LTT (weekly WAN show and what not) and Rossmann are concerned
As I mentioned before I (unfortunately) went into the GOS incident rabbit hole and overall still think Rossmann was principled.
As far as Rossmann's criticism of Linus about the LTT Honey case, perhaps he could have had a more nuanced approach, yes.
Regarding the BilletLabs cooling block, or the "Trust Me Bro", his criticism was substantive, and came from his own business background on dealing with customers (although you can argue that Rossmann has high standards).
I don't think Rossmann "fired shots for the wrong reasons", namely since LTT has publicly acknowledge the issues.
> If you want to criticize someone for being a jerk do it, but do it for the right reasons, don't muddy the waters by injecting other stuff in the discussion.
Just curious, but who is muddying waters, and how ?
> an operating system which essentially handles all of your private data.
This is exactly why one should continue using GrapheneOS as it is by far the best, most secure and private option. If you do not agree with one project member about something that is not related to the technical features of the project, it does not matter, since you can not be targeted with any GOS updates. Same updates would have to go to all GOS users and as stated before, the previous project leader has a stellar reputation when it comes to their work and prior actions regarding users security and privacy.
> the artist being "Google" and all their controversial practices
You believing this is a problem, you should then be using an iPhone anyway.
You are worrying GOS devs might push a malicious update, even when there are no proofs of that happening? What prevents the same from happening with other projects that are already inferior in every way? You are implying people should switch to less secure options because of this one thing that also applies to all other options? It does not make any sense and seems dishonest.
> Your logic seems to fall apart here.
>> an operating system which essentially handles all of your private data.
I will concede that my statement is not the most accurate.
However it is not a matter of logic, but description.
What I meant to say is that the OS is the substrate of all applications running on the phone, and all the relevant data.
Having privileged access to the OS opens the user to the most critical vulnerability.
> This is exactly why one should continue using GrapheneOS as it is by far the best, most secure and private option.
Rationally speaking yes.
When the developer of the OS threatens to "public expose you" and accuses you of directing harassment / swatting against them without evidence however, a layman (that has no obligation to understand how GOS updates work) is justified in feeling unsafe or uncomfortable using said software.
A determined enough (hostile) developer could find a way to target him personally. Even if you personally feel it is unlikely, the probability is ultimately non-nil.
The GOS x Rossmann matter was never a technical issue, it was about the (in my opinion) toxic approach of that lead GOS dev to Rossmann. A huge misunderstanding I dare say. But the damage was done and Rossmann is within his right to criticize his approach and stop using his software.
> Same updates would have to go to all GOS users and as stated before,
This is a irrelevant point. Stuxnet was harmless to most systems, while still targeting very specific Iranian systems.
All GOS user, (me included) don't audit the code every time there is an update.
> the previous project leader has a stellar reputation when it comes to their work and prior actions regarding users security and privacy.
Stellar reputation is quite the exaggeration. That lead GOS dev has an indeniable controversial and abrasive reputation.
Imagine the ingenuity and persitence that you perceive about his "work and prior actions regarding users security and privacy", and imagine it being deployed toward someone that dev does not deem as a "simple user", but a personal enemy / enemy of the project ?
Nobody would want to be on the receiving side of whatever such person is capable, and neither does Rossmann, understandably.
> > the artist being "Google" and all their controversial practices
> You believing this is a problem, you should then be using an iPhone anyway.
I will assume you are good faith, and just misread what I wrote.
My point was that in the same way we cannot trust Google software (at least privacy wise) because of the profit incentive of its leaders, another OS like Graphene OS can also inspire distrust if their leadership demonstrate hostile behavior (even if just toward a single specific user).
> You are worrying GOS devs might push a malicious update.
Me personally, no. I am not worried. I know enough about software to know that it is unlikely. And I am a nobody.
Rossmann is, because he is a layman, and the lead dev was clearly hostile against him.
We don't get to deny his perspective.
> even when there are no proofs of that happening ?
Not having proof of it never happening so far, is not a proof that it will never happen in the future.
> What prevents the same from happening with other projects [...]
Nothing prevents it, and no one involved either in this discussion, nor in the original incident stated this.
> You are implying people should switch to less secure options because of this one thing that also applies to all other options?
Again, nobody implied that. I personally never said it. My argument was that I found the leadership lacking, and to a certain extent, the community (examplified by this kind of "water carrying" arguments you have presented).
Even Rossmann himself never said it. He only made public his reasons for not mainly using GOS since the altercation, and still recommends it whenever he discuss phone privacy.
The grandparent however did bring up this issue with GOS leadership as a data point, which would still be good to have for prospective GOS users.
> It does not make any sense and seems dishonest.
If anything, you moving the goal post with such strawmen arguments is what seems dishonest...
> Just curious, but who is muddying waters, and how ?
In the context of this whole rabbit hole, pretty much all of the parties.
When you bring someone's dirt put in the public, not to support an argument but just to attack them because you don't like them, uou are muddying the waters.
MegaLag did it for Linus
Steve did for Linus
Luis did for Linus
Linus did for Steve
Linus did for Luis
Henry did for Daniel
Luis did for Daniel
And of course Daniel pretty much does for anyone :p
These were not conversations based on logic, each had a reason to dislike the other and dag up dirt for clicks and for leverage.
> When you bring someone's dirt put in the public, not to support an argument but just to attack them because you don't like them, uou are muddying the waters.
To take the specific case of Rossmann, how is he muddying the water ? If anything, he is clarifying his position on stopping using GOS. It is important context, not "muddying the waters".
You yourself say that:
> And of course Daniel pretty much does for anyone :p
And Rossmann brought up the receipt to corroborate the GOS developer hostile behavior toward him, which was his argument.
And even if you take it further back to origin, the "Informative but unfortunate" comment, this was not targeting GOS's quality and claim of security. The argument in that specific case was the questionable behavior of the leadership, which you seem to agree was not a "conversation based on logic".
If some people can't be reasoned with, what is Rossmann supposed to do ? He "agreed to disagreed" and cut contact with the dev, kept the GOS situation under the lid as it was still a project he liked, but that was apparently not enough to keep that developer at bay ...
> If some people can't be reasoned with, what is Rossmann supposed to do ?
Just stop interacting? When you have an argument with your colleague, do you go on twitter and post all your conversations and tell everyone how irrational he is? When you argue with a relative do you make an 1hour long video detailing how they missbehaved? Why did Luis felt the need to make content on his popular channel to expose someone with problematic behavior?
Clicks. Money.
And on top of that he is attacking his work which is actually very valuable.
I don't care if Luis is on the right side of the argument. If he was chatting me up on the bus and told me about it, i would be glad to know. Attacking a person on public for money and leverage is bs.
Edit: Especially in the case of Daniel, if you have made the conclusion that a person is trully paranoid, this is a clinical situation, do you expect to "fix" them by exposing them? Or are you throwing more gas to the fire?
> > If some people can't be reasoned with, what is Rossmann supposed to do ? Just stop interacting? When you have an argument with your colleague, do you go on twitter and post all your conversations and tell everyone how irrational he is? When you argue with a relative do you make an 1hour long video detailing how they missbehaved? Why did Luis felt the need to make content on his popular channel to expose someone with problematic behavior?
Rossmann did exactly in September 2022. If you actually bothered going through the document, would could see that they had an initial interaction that did not pan out. Rossmann wished Daniel best of luck and said he would not be further involved because of the disagreement.
On his social media and other platforms, Daniel did not stop talking about how Rossmann was allegedly attacking (without any concrete evidence). Daniel himself contact Rossmann again out of the blue with borderline threats blackmail umprompted, as can be seen in Rossmann's video on "Why I deleted Graphene OS". Asking nicely did not work, and Daniel threatened to "publicly expose him", so he went public. What was he supposed to do ?
> Clicks. Money.
Rossmann channel is not making him money. It is not monetized. His business is about repairing Macbooks and data recovery. This drama does not generate him money. He does not get paid for people using CalyxOS etc... over Graphene OS. There is simply no incentive
> And on top of that he is attacking his work which is actually very valuable.
What "attack" ? Is a comment "Informative but unfortunate" on a video criticizing Daniel's behavior an attack ? Is giving the project a 40K USD grant no string attached an "attack" ? Is proposing an to do interviews to further promote the project an "attack" ? Is making videos to actually dispel misconceptions about GOS and praising how good it is on his channel and "attack" ? None of you who carry water for Daniel and his toxic behavior have any evidence of Rossmann directing attack at GOS, and even loss so Daniel himself.
> I don't care if Luis is on the right side of the argument. If he was chatting me up on the bus and told me about it, i would be glad to know. Attacking a person on public for money and leverage is bs.
Again, no evidence it is about money and leverage.
> Edit: Especially in the case of Daniel, if you have made the conclusion that a person is trully paranoid, this is a clinical situation, do you expect to "fix" them by exposing them? Or are you throwing more gas to the fire?
Keeping it private the first few time did not seem to work, might as well try.
If Daniel himself is beyond help, at least make it so other people know what kind of person they are entrusting they phone security and privacy to.
You are exactly right. To summarise for those who do not want to watch a video, the video shows communications with Graphenes lead developer in which he was extremely hostile and threatened Rossman. It also goes into how said developers hallucinates being attacked by specific other sites, like a Linux YouTube channel that obviously did nothing to him. His goons then attack those projects.
You have to be aware that you give that person root when you use Graphene. All possible technical improvements aside this is a very big risk. He claimed he would step back after the video released, then called that a lie and continued with everything.
Calyx seems to be the best alternative right now without such a risk factor.
I second this opinion, with some additional nuance.
While I don't think the developers necessarily hallucinates being attacked (i.e. given the nature of the project, I would expect them to be persons of interest, be it from surveillance agencies, or even state actors), the main issue with Rossmann is their claim that he is either personally directing harassment against GOS, or colluding with and encouraging other communities to harass (mainly Kiwifarms, Techlore, CalyxOS, and other Android related FOSS projects).
This claim seems to originate then cascade from Rossmann leaving the comment "Informative, but unfortunate" on TechLore's video criticizing GOS's leadership.
This is taken as explicit support of TechLore community's / KiwiFarms alleged harrassement on the lead GOS developer, and this has somehow been cascaded and blown out of proportions, and considered by GOS developers as evidence of Rossmann's wrong doing against them.
As mentioned somewhere else, I am using GrapheneOS since 2 or 3 years now, based on Rossmann recommendations.
The software is very good, pretty much native Android experience, but without the extra alleged Google snooping / root access.
Rossmann himself seemed to have stopped using it as his main device because of fear of retaliation given that the GOS devs could potentially target him. Better safe than sorry.
I still use it because I am not that high profile of a person, and generally will use throwaway when it comes to discussing anything GOS related at this point.
The overall leadership however, based on Rossmann's and later my personal interactions with them however, did leave a bad after taste.
> Rossmann himself seemed to have stopped using it as his main device because of fear of retaliation given that the GOS devs could potentially target him.
But he didn't. It's clear in his later videos that he was still using GrapheneOS, I believe even for months after the video.
> Better safe than sorry.
People who are familiar with how GrapheneOS updates work wouldn't agree. No identifiers are sent to the update server, so targeted updates aren't possible that way. Also, update servers only host static files. If Rossmann was really that worried, all he'd have to do is use a VPN. But that was all just a huge dramatic act so his video would get more views, and possibly to entertain his fellow Kiwi Farms members.
> People who are familiar with how GrapheneOS updates work wouldn't agree. No identifiers are sent to the update server, so targeted updates aren't possible that way. Also, update servers only host static files...
We are literally talking about an OS here. It has an almost total control over your phone - what does it matter if the updates can be targeted? The GOS could snoop on their users and turn into malware only if it figures out that this is Rossmann's phone.
This is what is keeping me from installing GOS too. Interaction from the developers seems very aggressive towards the competing OSs, which doesn't inspire much trust. Who is reviewing the GOS changes? Are they really all benign? In the end you need to trust someone, but I'm not sure GOS is more trustworthy than LineageOS (which has a bigger community, more developers and /e/os building on top of them).
> But he didn't. It's clear in his later videos that he was still using Graphene OS, I believe even for months after the video.
Emphasis on "seemed to have stopped using it as his main device". For all we know, he kept it as secondary device (its just that good) after removing anything he deemed critical.
Again, he never said "don't use GOS", or "GOS is not secure".
He said he was did not feel safe enough because of the hostility from the lead dev.
> People who are familiar with how GrapheneOS updates work wouldn't agree. No identifiers are sent to the update server, so targeted updates aren't possible that way. Also, update servers only host static files. If Rossmann was really that worried, all he'd have to do is use a VPN. But that was all just a huge dramatic act so his video would get more views, and possibly to entertain his fellow Kiwi Farms members.
Does it matter ? Rossmann is a layman when it comes to software.
What he perceives is that "lead GOS dev is hostile against me and has essentially full control over the project".
First, he is under no obligation to spend hours learning how GOS updates work and audit the code every release, whether or not some identifier is being tracked or not (and by the way, you can still get identified and tracked even if you use a VPN).
The damage was done once that lead GOS dev persist in toxic behavior, for the lack of a better word.
> But that was all just a huge dramatic act so his video would get more views, and possibly to entertain his fellow Kiwi Farms members.
Unsubstantiated claims. We cannot read his mind, and I have yet to see any evidence that would support these.
> you can still get identified and tracked even if you use a VPN
Sure, but that requires additional data about the user, which the GrapheneOS update server doesn't get. Both the update client and the update server are open source, so you can verify any of what I'm saying. The server only sees the user's IP address, which device model they're requesting an update for, and which update channel (alpha/beta/stable) they are using. The HTTP headers, etc. for the request would be identical across any GrapheneOS device, as they use the exact same updater app.
But yes, I do believe that he's obliged to do some research before putting out such absurd claims entirely based on speculation with no technical knowledge or understanding.
All of you who keep commenting "But it's so easy, just look it up" are lacking consideration and empathy. Other people don't think like you, they don't have to think like you. Just the documentation you have linked has so many technical terms, someone not familiar with networking and system design will barely make any sense of it.
It is a also a matter of trust. After the developer express their hostility multiple time, even if someone was willing to go through it, what if the documentation is not forth coming ? It is within the devs control after all.
How does one even make sure that the software does what the documentation says it does ? etc...
> But yes, I do believe that he's obliged to do some research before putting out such absurd claims entirely based on speculation with no technical knowledge or understanding.
What "absurd" claim did he put out exactly ? His issue was never about the technical aspects of GOS. It was about the broken trust and the perception that using software from a hostile developer was a risk factor, hence his stopping using it (at least on his devices with sensitive info).
Calyx has lackluster security practices, and even removes signature checking so they can sell microG as Google Play Store to apps. This is an objective statement, graphene OS is leagues ahead of anything on the market in terms of security, while calyx is basically just a custom ROM to tinker with.
As for the personal aspect, the lead developer is definitely not the best representative of the project from a communication perspective as he might not have that kind of social skills (based on his posts). [1]
But he (Micay) is an excellent security researcher, and has an excellent track record when it comes to prioritizing his users. There was a sponsorship in the beginning, where the legal entity, CopperheadOS tried to hijack the whole project. But Micay rather kill the project, than let the users' security suffer and revoked the signing keys. And I'm sure such a betrayal would cause anyone to lose a lot of faith in others' actions.
> Give that person root
Complete bullshit, what root?! And if anything, you are the one who are trying to discredit a project here, by sharing some dumb clickbait video.
[1] I see that there is now a project manager doing most of the communication, which is an excellent solution!
Do I have to explain what root is, or what are you not understanding about the concept of the software provider having complete control of the software on your phone and thus having root rights?
Your CopperheadOS description is one perspective, one that does not look all that believable now after his mental illness became clear.
I did not share the video, but I would and it is not clickbait.
I will not further respond to you, I don't think this would lead to a fruitful discussion. Kindly think about what kind of trust is necessary to trust in the proper functioning of a device as personal as a modern phone, and think about attack scenarios that could occur when the main developer of your OS is not trustworthy in the slightest.
Here you are again in yet another comment repeating these baseless claims about mental illness.
> think about attack scenarios that could occur when the main developer of your OS is not trustworthy in the slightest.
First of all, he's not the main developer. There are multiple developers. The other developers do most of the development work these days.
But to say that the OS is untrustworthy is completely false. You say GrapheneOS's founder has a mental illness based on watching a video where someone turned malicious toward the project recorded a conversation where the founder was extremely upset after being swatted multiple times.
The update client doesn't send identifiers when checking for updates, and the update servers only have static files saved to them. You're making stuff up here, and clearly trying to turn people off of using GrapheneOS by repeating baseless claims that the founder is crazy and fake worries of being targeted by them.
There's way much more to it than what you said here.
> extremely hostile and threatened Rossman
At the time, he was very upset. You know, because he was swatted multiple times. Of course he was upset when Rossmann showed his true colors and was trying to talk to him. Rossmann saw this as an opportunity and recorded it as it was happening. He tries to portray Daniel as crazy and people who attack the project and his friends on Kiwi Farms lap that stuff up.
It's not true that he stopped using GrapheneOS, though. He continued using GrapheneOS for months after that video, which you can see by watching his later videos.
> hallucinates
Repeating baseless claims that he's crazy.
> You have to be aware that you give that person root when you use Graphene.
What? This is a very strange way to say it. Either way, it's literally impossible for someone on the GrapheneOS team to target someone like what was claimed in the video. GrapheneOS devices don't send identifiers when they contact the update server. The update servers also only host static files.
> Calyx seems to be the best alternative right now without such a risk factor.
The "risk factor" is completely false. It's all made up to attack GrapheneOS, making the founder look like a crazy person, then people are scared of using the OS. CalyxOS is not a hardened OS and rolls back security in some ways. It's not the next best alternative for people who care about these things.
Nothing I said is baseless and contrary to you, I do provide sources.
> Of course he was upset when Rossmann showed his true colors
I saw the chats. You lie. Showing his true colors = not accepting that there is an evil conspiracy and asking for proof. You are completely brainwashed and I will not continue this discussion.
If Calyx is not the next best alternative be invited to link to what you think is the best alternative. I still think it's Calyx.
It has they initial conversation and disagreement in September 2022, after the GOS developer in question accuses Rossmann of being complicit with harassment campaigns again said dev., because he also gave the same 40K USD FUTO grant to other similar project and had some interview with their developers.
The second set of files are the text messages that feature in the video, after said GOS developer contacted Rossmann umprompted on May 2023 with the same type of accusation.
I'm responding to it directly, the main source is the video linked in parent of this thread. Its description contains further links. I also did link to a relevant statement from the developer in a subthread here.
The main source is the video, where you can see the GOS developer writing him live.
For more context, there was a Google Drive link that is unfortunately not available anymore, but I found and uploaded it here: <https://www.swisstransfer.com/d/d75ff782-4a7d-4497-b04e-edd1...>
It has they initial conversation and disagreement in September 2022, after the GOS developer in question accuses Rossmann of being complicit with harassment campaigns again said dev., because he also gave the same 40K USD FUTO grant to other similar project and had some interview with their developers.
The second set of files are the text messages that feature in the video, after said GOS developer contacted Rossmann umprompted on May 2023 with the same type of accusation.
Can you elaborate on why this is a risk factor? What do you mean by saying we're giving him root? If a person is paranoid of being chased i would expect them to put even more effort into the security of the OS he develops, not to add backdoors. But please expand your own reasoning.
To put it simply, the (at the time) lead developer of GOS and Rossmann had some disagreements.
At the time, Rossmann was mainly using GOS, but due to what he perceived as hostile behavior from GOS toward him through their communication, he opted to stop using GOS (at least on his main device, as he claims).
His rationale was that the behavior of said lead developer was not "rational" and "scary", and since the developer has not only edit access to GOS code but also update publishing infrastructure, Rossmann's data or himself could be targeted through malicious code pushed via an update, for example.
While GOS is opensource and malicious code or exploits could be detected by the community, he himself did not have confidence to audit the source code to make sure it was safe, hence his decision to stop using.
By risk factor, I think the grandparent suggests that something similar could happen to someone else using GOS, the risk factor being essentially at the mercy of GOS developer, would they wish to harm said user.
> Rossmann's data or himself could be targeted through malicious code pushed via an update, for example. While GOS is opensource and malicious code or exploits could be detected by the community, he himself did not have confidence to audit the source code to make sure it was safe, hence his decision to stop using.
This isn't even possible given how updates on GrapheneOS work. The update client doesn't send identifiers to the update server, and the update server only hosts static files.
Rossmann either doesn't understand this, or he made it up to get more views, or possibly to entertain fellow Kiwi Farms members.
To be honest, I don't think that he didn't understand that he couldn't be targeted. He continued using GrapheneOS for months after the video. As I understand it, it was clear in a few videos months after the initial video was published.
> This isn't even possible given how updates on GrapheneOS work. The update client doesn't send identifiers to the update server, and the update server only hosts static files.
> Rossmann either doesn't understand this, or he made it up to get more views, or possibly to entertain fellow Kiwi Farms members.
Expecting a layman to know that is not reasonable. The argument is not about the GOS updates work in practice.
It is about the "perpection", from Rossmann's perspective that the lead dev of the OS is hostile against him.
Humans are not purely rational machines, and given the choice of either 1) spend hours auditing source code and updates pipelines (every release ?) and 2) stop using it for critical purpose, the latter is the easier choice, especially for a busy person like him.
> To be honest, I don't think that he didn't understand that he couldn't be targeted. He continued using GrapheneOS for months after the video. As I understand it, it was clear in a few videos months after the initial video was published.
For all we know, he is using it on his secondary device where he has removed what he deems critical.
Again, Rossmann NEVER said "don't use Graphene OS", or "Graphene OS lack security" or anything of the sort.
If anything, even after that video, he kept recommending GOS whenever he talked about privacy.
His argument is that he did not feel safe knowing using software from a hostile developer; and that he can't be bothered / not qualified to audit the code well enough to make it worth it (which is reasonable if you ask me, and I dare say most people).
Edit:
> Rossmann either doesn't understand this
Again, I agree with you here. He does not understand. He trusted the developer(s) to know what they are doing, but they broke that trust by being unreasonable, to say the least.
He is under no obligation to understand.
As for what you stated after that, I won't comment on it as I don't read minds, and pretty sure neither do you.
Note that this patch would have to be sent out to all users though, since I don't think there is an authentication mechanism that lets them send out different upgrades to different users.
And if your whole business is a secure OS, it's a very risky proposition: you get caught doing this once, and your reputation is gone forever.
Your example is a strawman, as a determined enough actor, especially a security expert(s) like GOS developers could pull it off and get such patch / exploit.
The probability is not zero.
It will probably not be obvious to spot, would be spread over multiple files of code that don't necessarily relate to each other at first glance, as many documented CVE illustrated (one that comes to mind given HN context is the XZ utils backdoor from last year for e.g.)
Rossmann himself has no confidence to audit the code, so why take the risk ?
Good enough reason to be "paranoid", or at least feel uneasy about it if you ask me.
Is it really a strawman? At some point, the code would need to identify rossmann. Please elaborate on the techniques required to do it and how it could be obfuscated.
GOS doesn't use an account, so the code would have to perform very targeted heuristics in order to verify this is Luis' phone. It would have to compare his sim number against a known one, or dig into application data to find his logins and compare them against known emails. So the only way to not write `if (user is rossmann)` would be to send various diagnostics over the wire, to a service that contains these identifiers and perform the comparison onlinr, meaning he would introduce an imense security whole into everyone's phone, and everyone would see there is a home calling.
So it's either a patch of if user == rossmann, or a home calling patch.
> Is it really a strawman? At some point, the code would need to identify rossmann. Please elaborate on the techniques required to do it and how it could be obfuscated.
I don't have to elaborate techniques. If a determined (and potentially mentally unstable) developer decides to leverage their full control over the OS to make it happen can. I don't have to elaborate on the techniques which might or might not exist yet.
Stuxnet only targeted specific Iranian systems, a needle in a hay stack, was spread did not harm random devices across the globe, and stayed mostly undetected. And this was done without "developer access" to the software itself.
Is it hard ? Yes. Is it likely (especially given the knowledge of how GOS works) ? Perhaps not. Is it impossible ? Definitely not.
When the lead dev of the OS you use daily threatens to "publicly expose you" as a user, I won't blame said user to stop using the software. And even less, to provide such data point regarding the behavior of that developer.
Well, he can do everything to your phone, software and data by pushing software updates. When there was a dispute in the former project copperhead he deleted the cryptographic keys, blocking software updates. Paranoia could result in just making the system more secure, but why not add a backdoor to find the spies in your userbases that communicate with the black suited men that secretly run our government? After all it is easy, they all play a specific game where they communicate via secret messages in chat.
You just don't know what will happen is what I'm saying.
The "he has root" is also a reference to ubuntus shuttleworth.
> when there was a dispute in the former project copperhead
You mean who tried to hijack the project in a very questionable direction, harming their users, he rather lighted the project on fire then let the users' security be compromised?
If anything, that is the greatest compliment you could give him.
Also, this is fud that he can push any kind of code, like you can easily check any part of the pipeline.
> You mean who tried to hijack the project in a very questionable direction, harming their users, he rather lighted the project on fire then let the users' security be compromised?
> If anything, that is the greatest compliment you could give him.
On one hand, sure it can be a compliment.
On the other hand, it only increases the perception that he is could enact significant harm if he ever comes after you.
> Also, this is fud that he can push any kind of code, like you can easily check any part of the pipeline.
Who is "you" ? Neither Rossmann, neither me (software dev albeit not in cybersecurity), and even less so the average GOS user, and I would venture to guess that neither you can audit GOS code with enough confidence to declare that the risk of an exploit or backdoor being introduced is zero.
Open-source is not a guarantee that code or software is secure (for e.g. CVE in xz utils and many such cases).
> On the other hand, it only increases the perception that he is could enact significant harm if he ever comes after you.
But that would be incorrect. It's not possible for anyone from the GrapheneOS project to target a GrapheneOS user that way. Look into how updates and the update servers work.
> neither you can audit GOS code with enough confidence to declare that the risk of an exploit or backdoor being introduced is zero.
The updater app is pretty easy to read through. I think a software developer would be able to understand it. The update servers' setups are also very easy to understand. It doesn't take a software developer genius to figure these things out.
> But that would be incorrect. It's not possible for anyone from the GrapheneOS project to target a GrapheneOS user that way. Look into how updates and the update servers work.
My point is that from Rossmann's perspective, being target of the lead GOS software dev hostile behavior as per his "Why I deleted Graphene OS" induces Rossmann's --> perception <-- that the GOS could go after him if he really wanted to.
First, everyone is busy and has their life, suggesting that his spend hours going through code and documentation he is not familiar with to make sure he is not target is moot. Most people don't read TOS, and same goes for Licences and docs of OSS.
Between doing that and stop using it as it's main device OS, the easier choice is the latter.
As a software dev myself, your expectation of layman being able to navigate something like a code review, or even an investigating an exploit is hardly reasonable.
So it is not "incorrect". I am not even saying Rossmann could be targeted. I cannot even make this claim as I have not gone through the docs nor understand the build and update pipeline, which is kind of my point: I can't be bothered neither for GOS, nor for the most of the FOSS software I use. The majority of OSS user rely on the vague concept that motivated and honest people audit the code, but hardly anyone is going deep dive into how an arbitrary piece of software works.
The main issue is the attitude of that GOS developer, whether they like it or not, taints the confidence in the project.
it does not matter if Rossmann can or cannot be targeted technically.
The issue here is not technical but a reputation issue.
> The updater app is pretty easy to read through. I think a software developer would be able to understand it. The update servers' setups are also very easy to understand. It doesn't take a software developer genius to figure these things out.
Even then, it could be argued that the rules in place could be changed to introduce malicious exploit if the lead dev(s) were motivated enough.
Especially given GOS relatively top-down structure, relying essentially on a benevolent dictator.
Even if I made the effort, then ascertain there was no vector attack, now I have to stay on alert every commit / release version and spend as much time looking for a targeted exploit ? etc...
Update server setup might be clean, but an admin could SSH or gain access in some way or another and do rogue changes, were they determined enough.
The probability is not zero.
Again, the problem is eroding the trust of the specific user (Rossmann in this case).
Wow. Reading and responding to your comments in this thread, I can see you are very motivated to trash GrapheneOS and its founder.
> Well, he can do everything to your phone, software and data by pushing software updates.
Other developers are doing the bulk of development work these days, so this is nonsense.
> Paranoia could result in just making the system more secure, but why not add a backdoor to find the spies in your userbases that communicate with the black suited men that secretly run our government?
Again with the baseless claims that he's crazy. Your argument here is that "he is crazy, so maybe this happens too." It's nonsense. There are no backdoors, and if there ever were any backdoors, they would be found. GrapheneOS isn't some small project that nobody knows about. It's famous for being very secure, even famous people have said publicly that they use it or others should use it. Cellebrite cannot even hack into it. Backdoors wouldn't go unnoticed. This is also nonsense.
"Never meet your heroes". Also, the opening monologue to Tool's Third Eye[0].
The older I get the more examples I've come across of a person destroying their reputation by either self-over-exposure (social media) or just basic exposure via news of some outrageous or illegal behavior.
I don't have a problem with whatever line you choose to not cross, and I was once much more self-righteous, but I've more recently pretty much made the conscious decision to separate product from producer, art from artist, etc.
Theo Lengyel was recently arrested for murdering his girlfriend, and yet I will still listen to and enjoy Mr. Bungle's music.
Gary Glitter... I still like the song Rock n Roll Part Two.
J.K. Rowling has some controversial views on transsexual women, but that doesn't mean that the Harry Potter series is any less worthwhile reading than it was before.
ReiserFS
I still buy Nestle Quik occasionally
Steve Jobs, Bill Gates, Mark Zuckerberg, name almost any tech bro... (but not Steve Wozniak, he's a treasure)
Sports stars.
Musicians.
I wonder how many other things are worthy of protest if we knew all the facts about all the people who were involved in it's creation.
(I'm attempting to respond to the general concept of "he/she/they bad = it bad", not commenting on GrapheneOS vs CalyxOS or anyone's personal choice over where / what they choose to apply "he/she/they bad = it bad" to, other than saying that it should be a conscious decision not a reflexive reaction)
This a video where he openly bullies someone, live streams their private messages where they're getting upset with him bullying them and repeatedly, blatantly lies about them including falsely claiming they're insane, etc.
Rossman lied about stopping using GrapheneOS and has continued using it after that point.
The video was made to direct harassment towards the project and founder after the project refused to work with Rossman.
He has done similar things to others, labeling them as insane and delusional.
> This a video where he openly bullies someone, live streams their private messages where they're getting upset with him bullying them and repeatedly, blatantly lies about them including falsely claiming they're insane, etc.
That is the most disingeneous take on the video.
The claim this kind of commenters that freely carry water for the toxic GOS (ex-?) lead developer is the exact reason why Rossmann made the video.
The evidence is all there for the public to see.
Daniel does not get to essentially harass people he disagrees with after they have been asked to not contact them, threaten them to "publicly expose them" and get away scott free.
Being a genius at cyber security or autistic does not give one a free pass to treat other like garbage.
> The video was made to direct harassment towards the project and founder after the project refused to work with Rossman.
The video was made to expose the harassment of the project founder toward Rossmann, when the former contacted him out of the blue with frivolous accusations after they parted way a year earlier due to un-reconciliable disagreements.
> He has done similar things to others, labeling them as insane and delusional.
Yes, I have watched them all.
As I mentioned somewhere before I am a fan of both channels.
He never called Linus "insane" or "delusional" as the parent post claims, hence the request for evidence.
He (rightfully IMO) criticized some of his business practices (Honey, BilletLabs, "Trust me bro"), and quite a few more controversies which LTT was embroilled in.
He criticized Linus' behavior and lack of accountability based on his personal interaction with him, as well as publicly available evidence. At worst, called him a narcissit.
If anything, he is vindicated by all the LTT apologies videos (one of which Linus and other staff even make puns and sponsor placements ...) that follow up each controversies.
Any more specific evidence you think show that "Rossmann has the habit of calling random people insane and delusional".
I am willing to bet you have none.
The article mentions the lack of a swipe keyboard, which is an issue for me.
There is an option though: Heliboard with a custom swipe configuration applied (which is apparently sourced from Google, I'm not sure how "grey" that is).
It definitely works as a swipe keyboard, but it's just not as good as GBoard. I will persist, however. I hope that it's learning at least...
some things about the UX in this is so bad, which i love because it discourages me from using the phone more. every time i end a phone call i struggle hanging it up. i don't know how to go forward in the browser because the swipe always makes me go back, even when i swipe forward. it's using the ugly material ui components from google. it's great!
all of the privacy and security parts of the UX are good, though.
You don't need to wipe the phone when updating GrapheneOS. It's as painless as on stock Pixel OS. OTAs downloaded and installed on the background, just reboot the phone after.
Does Vanadium include the necessary APIs for uBlock Origin? Otherwise this seems like having a long explanation of how secure the windows are with titanium frames and bulletproof glass while the front door is wide open.
uBlock origin won't save you from exploits in Firefox. The only way it would've might save you is if you disabled first-party JS, which you might as well just disable in the browser itself.
Chromium still is the superior browser in terms of security and Firefox is way behind. Adding an extension so you _might_ have less security exploits in the foundation is a wrong tactic and should be avoided.
Real world threats generally aren't exploiting process memory errors or whatever. Unless they're in the shadier parts of the web, users are unlikely to encounter such things even when they might exist. Spyware and adware threats on the other hand are ubiquitous and highly likely to be encountered by nearly everyone. A web browser that doesn't mitigate that is simply not fit for purpose. It's a table stakes security requirement.
My personal favorite feature of GrapheneOS is that we can toggle the network access permission.
In the past, I'd have to root my phone just to be able to install a firewall to do the same.
Big props to GrapheneOS!
Big thank you to the GrapheneOS team! I have been running it for a week now on my 9pro and the user / app sandboxing is great. If there's a way to donate with cryptocurrency or help contribute, let me know!
We recently made it so that the call recording option is not hidden away. If there are 7 options, it's RTT that will be the last one now, and we've made the scroll bar always be visible to make it clearer to people that they can scroll there.
It's a shame that Android as a whole is trending towards hardware remote attestation. It's pretty much guaranteed that app developers will eventually start writing their apps so that they refuse to run on anything that doesn't pass Google Play Integrity. Being unable to run WhatsApp or bank apps on GrapheneOS will render it useless as a smartphone operating system. It might not be happening right now but the threat of it looms eternal. My bank could flip a switch somewhere and suddenly my phone becomes useless for the purpose of accessing my bank account.
The Google Pixel requirement also makes me sad. I understand that they have solid reasons why. The problem is Google is incapable of selling their phones worldwide. It's really embarrassing for Google and unfortunate for me.
Not at all. They are one and the same. Both of those things will literally destroy the computer freedom we enjoy today.
GrapheneOS can attest to the device's security. The question is whether the app developers will trust such an attestation. Will they put money, time and effort into evaluating and trusting GrapheneOS? Of course not. They will just decide to trust nobody except Google and Apple.
This is the future. We'll be discriminated against. Can't even log into an account from an "unauthorized device". Their servers will just refuse to talk to our phones if they can't cryptographically verify that we have not "tampered with" them. We'll be refused service straight up unless our computers are straight up owned by corporations.
This so called "integrity checking" is meant to protect the corporations from us, not the other way around. It's so we can't do things like hack our way around their "policies".
Well, there are examples such as Yuh and Swissquote which are using Play Integrity API and also using hardware attestation to specifically allow GrapheneOS. The latter is in the process of implementing what's needed right now.
We also expect Google's Play Integrity API to inevitably be ruled as anti-competitive, which it is.
I think Graphene gets posted here yearly. Having tested a variety of ROMs dedicated to different elements of security, I can attest that Graphene allows the most "normal" phone usage compared to many others. The biggest factor is the sandboxed Google Play Services, which allow you to use a lot of apps that you wouldn't be able to otherwise.
I've used Lineage without MicroG, as a comparison, and that's becoming more-and-more unusable every day some lousy Android developer tethers their company's app to some feature exclusive to Play Services.
Google Pay is not available on any alternative OS due to Google blocking it. It's unfortunately their choice, rather than a lack of support on our end.
Depending on where you are in the world, there might be other NFC payment options for you.
In the EEA and UK, Curve pay works. Paypal made their own solution and is rolling it out, starting with Germany. Both work with GrapheneOS. Many banks also have their own solutions.
Maybe my tinfoil hat is on too tight, but I always thought it was interesting that Graphene OS places so much blind trust in a proprietary black box security chip from Google that they pinky-promised to open source but never did.
Because they are a software project. When you're only concerning yourself with software, you have to pick some hardware and move on.
Going down the rabbit hole of secure hardware leads you down a slippery slope of eventually needing to create your own chips. And that's basically impossible these days for anybody smaller than Google or Samsung. So you do some research, pick the best you can, and hope for the best.
OpenTitan has open silicon (RISC-V) and is capable of open firmware (based on Rust TockOS) and is coming to 2025 Chromebooks, https://news.ycombinator.com/item?id=44416304. Hopefully a derivative of OpenTitan will ship in future Pixel devices.
Google Pixel hardware provides nested virtualization, enabling a Debian Arm "Linux Terminal" in pKVM/AVF VM, with use of Debian package repos.
Are you referring to the titan M2? why do you describe Graphene OS putting "so much blind trust in" it? I don't think they put much trust in it besides using it for storing keys and for their "Auditor" app
> I don't think they put much trust in it besides using it for storing keys
Ummm. Was this sarcasm that went over my head? Because if not, I have a hard time thinking of anything that requires as much trust as your private key storage.
If you think the org that produced the hardware might have backdoored it, architecting your software to avoid the TPM or whatever is dumb. Targeting Google HW at all is an unavoidable act of complete trust so you might as well use the HW properly.
Also, why would Google bother backdooring their special HW when 99.999% of its users are anyway gonna be running a totally Google-controlled proprietary SW stack?
> Targeting Google HW at all is an unavoidable act of complete trust
Doesn't the existence of FHE downgrade that to just "complete practical trust" at least? Not that I know of it being employed, but that it could be, and that it may be worth shouting out exactly cause of how niche and impractical it is.
We are talking about hardware here so ultimately you need to trust some manufacturer, software algorithms don't help.
With SEV-SNP and Intel TDX I think it's possible to build a hardware platform that doesn't require the user to trust the OEM although they still need to trust at least one large American tech company that controls the root of trust.
But I don't think this is ever gonna happen for consumer devices. AFAIK it's only sorta kinda happened for any real-world platforms at all (but maybe someone can correct me).
Ultimately if your threat model includes Google as a potential adversary, and you are not in control of nuclear weapons, you are gonna have to make some serious sacrifices to achieve security IMO. Smartphones are out. (Actually, I guess if you trust China you have a way forward).
There are some corrections that we have contacted the author about regarding the history of the project. They initially e-mailed us to ask a few questions but seems to have maybe misunderstood something.
For clarity, GrapheneOS is the continuation of CopperheadOS, not a new project that spun off from it.
As an example, it can be seen that our repositories and legacy bugtrackers are ours:
It's a direct continuation, but was renamed to GrapheneOS post the failed takeover attempt. GrapheneOS has persevered and is all the stronger for it. Over a decade now. :)
That is not correct, or at best a very questionable interpretation. Graphene is a continuation of the open source side of copperhead, but the copperhead project continued to exist even though the Graphene dev sabotaged it by deleting the cryptographic keys. Copperhead is the continuation of copperhead is my reading, Graphene is just also a continuation in a different project.
Why lie about something so easy to disprove by a bit of research? There were a bunch of articles about this back then, even wikipedia states it clearly.
GrapheneOS (like all modern AOSP based ROMS) can literally not function with just the open source code. It requires hundreds of binary blobs from the vendor partition of a stock Android ROM, many of which have root access and have not been audited by anyone, including Google, who often lacks source code for them.
Beyond that, the GraheneOS team still controls a single signing keychain for all phones in the wild, which we have to assume is still controlled by Daniel Micay (strcat) as it has not rotated as far as I can tell since he mostly stepped away from public view.
He is without question a brilliant security engineer, but we can't ignore his very public Terry-Davis-esqe history of mental illness. Making -anyone- a single point of failure for a ROM frequently recommended for journalists and dissidents is a bad plan, and especially not someone very prone to believing wild conspiracy theories.
I can't recommend GrapheneOS for any high risk use cases until:
1. they are able to find a device they can run 100% open source code on with no binary blobs
2. The ROM can be full source bootstrapped to mitigate trusting trust attacks.
3. The ROM builds 100% deterministically and is reproduced and signed by multiple team members publicly
4. Threshold signing or a quorum managed enclave issues the final signature only if multiple team members give it signed approvals of a hash to sign.
Until at least those points are covered, the centralized trust model of GrapheneOS is a liability and the central keyholder is at high risk of being targeted for manipulation or coercion.
Honestly there is no good solution to these problems right now, and as a security and privacy researcher my best advice today to potentially targeted individuals is don't carry a phone at all, or if you must carry one, keep it in airplane mode whenever possible and do not do anything sensitive on it. Consider QubesOS or AirgapOS for such things.
If you are fine with centralized control of a phone, and fine with binary blobs controlled by random corpos having God access to your device, but would prefer to eliminate as much proprietary corpotech bullshit as possible, then I would suggest considering CalyxOS which is at least run by a former LineageOS maintainer with a great reputation.
So you're saying don't use a smartphone at all, which isn't possible, or use CalyxOS, which not only suffers from the same "problems" you criticize in GrapheneOS, but is also inferior in every way when it comes to security and privacy?
> don't use a smartphone at all, which isn't possible
I run a b2b tech company in Silicon Valley and have not carried a smartphone in 5 years or had an LTE subscription in 6. I have a family and hang out with friends, mostly tech workers, at least once a week. I am online when I am at my desk or one of my family PCs, otherwise I am offline. It has been a massive productivity boost, attention span boost, and social improvement in every way.
I don't miss hours of doom scrolling a day and missing out on being present with friends and family. Took a few weeks to rewire my dopamine engine so the FOMO went away.
Phones -are- optional and if you think otherwise you might be an addict.
> CalyxOS, which not only suffers from the same "problems" you criticize in GrapheneOS, but is also inferior in every way when it comes to security and privacy?
It is better in one way: a reasonably stable person holds the keys to the kingdom. Personally I do not like having -any- central person controlling my devices, so I just opt out of Android entirely until that situation changes.
I am a supply chain security researcher and founded a Linux distro where no single computer or maintainer is trusted, so trust decentralization, freedom, and control in software are very important to me.
> my best advice today to potentially targeted individuals is don't carry a phone at alil
Lol. I hope you like working with geese, but be careful, they can't be trusted!
Also, you are pretty much factually wrong on a bunch of items on your list. GrapheneOS still has room for improvement of course, but they are very ahead of anything else on every aspect. And where you are not factually wrong, you are just unrealistic. There is no 100% open-source hardware, period. This is complete "what color you want your dragon to be" category.
> Lol. I hope you like working with geese, but be careful, they can't be trusted!
Geese? That is offensive. I raise chickens.
I also run a successful tech company, and have a full EE lab, several full server racks, and more tech in my home than anyone I have ever met.
Phones are completely optional in modern society. We have just convinced ourselves we need them because doom scrolling and constant notifications are addictive.
Print your boarding pass, ask for paper menus, pay with cash, and arrange times and places to meet people and then actually be there on time. The rare times you really need to do online work on the go, bring an actual computer with a real keyboard. Free wifi is everywhere.
Works just fine, and as a bonus your time away from home becomes mostly invisible to marketing firms.
It is insane the amount of "news" about GOS that somehow get things wrong.
It cannot be coincidence but misinformation on purpose.
On Twitter, GOS team have to often reply with the actual correct information, it is insane man.
Reading some comments here regarding hidden profile, security through obscurity doesn't and will never work.
Add to that the fact that GOS is well known now, those people think that if they were forced to give their phone away, they won't have to disclose the hidden profile??? Newbies!!
I don't wonder why GOS team never bothered to prioritise this.
I have been using GOS for a few years now, it is perfect, full control over everything, the teams support is like no other and full transparency about everything, the release notes are like no other.
The one thing that prevents me from switching my Pixel over is the lack of support for emergency services to see your location if you call the emergency number. I know this because I called twice while having GrapheneOS installed.
I do some watersports and always take my phone with me, so letting emergency services see my location is good for my safety in case I ever got into trouble on the water. I also have a PLB, but I like to have two devices for redundancy, as is best practice.
It sounds like you're in a region not supporting E911 but rather depending on Google's proprietary Emergency Location Service. We plan to make our own implementation of what that provides:
GrapheneOS supports E911 and has our own network location implementation you can enable which gets used by it. Unlike Google's implementation, our network location is based on location position estimation similarly to iOS. Unlike iOS, we'll be providing full offline support for it.
Counter-point: Pixel 9 with GrapheneOS, location services off, Netguard installed and active; I engage with emergency services on a regular basis for work and always receive the public record which tracks the incident. The reported coordinates are almost always within 100' of my actual location, so YMMV.
GrapheneOS supports E911. It doesn't have Google's proprietary Emergency Location Services implemented as part of Google Play services which some countries depend on. We plan to implement the same standard it does for regions without support for a variant of E911:
If it's just for trying out, then go for the cheapest second hand Pixel that's still supported by GrapheneOS and still has a battery that can hold charge for as long as you need it to for testing.
I bought a second hand Pixel 7a for my recent migration. Battery isn't great, but it's good enough to get me through a day.
As a long time GOS user I just want to remind what a joy it is to see my very old phone outlive flagships due to the lack of bloatware. I upgrade phones just for a single reason: it has been physically hit so hard over the years that it stops being physically functional.
What if all this hype about GrapheneOS was actually deliberately invented by the CIA so that everyone who has something to hide would install a beacon with a backdoor on themselves? adjusts tinfoil hat
While a big proponent of this, to my mind, it seems a bit counterintuitive to place your trust in a community who will probably cannot be held into account once some bad actor slips into their ranks, creates a bad patch and empties my bank account.
It's important to note that GrapheneOS is not some niche barely-used project. It has existed since 2014 and is used by multiple hundreds of thousands of people at this point. There are also many eyes on the project through people forking it to make their own products, people maintaining their own builds etc. GrapheneOS is also reproducible in addition being open source.
On our side, we are very particular about accepting outside contributions if they don't need meet our standards, and code is heavily reviewed within our team before being merged.
All in all, your concern, while valid, isn't something that's likely to happen precisely because we're very aware of situations where it has (see xz) and are therefore very vigilant. The kind of thing you're worried about isn't likely to come from a big project like GrapheneOS that has many eyes on it, but rather something small that's used everywhere and barely has a couple of devs working on it, if that (again, see xz).
Funny how your mayer example is actually proprietary closed-source software. So being an open source project carried by a large community doesn't seem to be an actual drawback -- if at all, a Solarwinds-like attack is far more improbably to succeed in a popular and well run open source project than in the darkness of closed source.
> it seems a bit counterintuitive to place your trust in a community who will probably cannot be held into account once some bad actor slips into their ranks, creates a bad patch and empties my bank account
From what I have observed, nobody is held to account when there is a software issue, commercial or open source.
>counterintuitive to place your trust in a community who will probably cannot be held into account once some bad actor slips into their ranks
Open source software is everywhere. Do you think Microsoft or Redhat going to be held to account if they accidentally added some backdoored OSS code? Moreover all of the development happens in the open and you can build it yourself. I'm not sure what the alternative is. Just trust Apple has their shit together with iOS?
This take demonstrates most people's inability to rationally threat-model: you would rather trust a known-abusive authority than an unknown-good samaritan, because of a false notion your bank balance is actually significant enough to warrant such an attack.
Google also cannot be held to account, its legal team out resources countries and if you attempt to litigate at best they will just keep you busy until you're bankrupt.
At least graphene wouldn't be expected to shield the perpetrator.
You say the same thing about Linux? This feels like old open source FUD, the only case I know of off hand is the xz util backdoor and that was found and patched before the malicious patch had made it into the main distribution channels.
I see some core team on this thread, so just wanted to say THANK YOU! Awesome job! Keep fighting for the users!
I'm totally the wrong person to offer recommendations on mobile, but so far it works very well for me, but then, I use almost no third party apps, and none of them are Play store only. My only complaint is the hardware (outside of their control).
reply