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".
I've got a Pixel 9a expected to arrive today, specifically for it to run GrapheneOS. One of my old phones was a Nexus 6P running CopperheadOS (prior to the dispute that spawned GrapheneOS), and it was great back then. Looking forward to how things have progressed in the years since.
I wish GrapheneOS would support non-Pixel hardware, though, specifically my Fairphone 4. I get why that probably won't ever happen, but it feels like a massive regression in terms of repairable hardware to move away from that.
Except the default browser is Chromium with some changes
This reminds me of a recent HN comment I saw that suggested using Firefox was "kicking Google where it hurts" or something like that
Like Firefox, this project depends on Google. For the hardware, the web browser and who knows what else
It even offers a sandboxed Google Play Store
It tries to copy Google paternalism
It swaps a Google mothership for a Graphene mothership
What if the computer owner does not want a mothership
Can connections to Graphene servers be blocked, i.e., are these connections optional or mandatory
Even Netguard which works on any hardware and does not require root makes unnecessary connections to ipinfo.io servers effectively giving them a list of almost every domain the user's phone trying to access
If the concern is apps that only require internet connection for ads, Netguard solves that problem without root
Most apps but not all will try to connect to the internet at some point, even if you never use them
The user-hostile design of Android is that apps keep running in the background after they are "closed"
(There are crude apps one can use to automate manually killing each process with "Force stop" but no one uses them. This doesn't prevent apps from trying to access the internet on some preset schedule)
Netguard will show when apps try to connect and block the connections. It provides DNS logs and PCAPs.
One does not even need Netguard to see this subversive activity
Try this at home
Enable IP forwarding on a computer you can control, i.e., one that is running an OS you can compile yourself such as Linux or BSD
Put the phone on the same network as this computer
Set the phone's gateway address to the address of the computer
Run tcpdump on the computer and filter for the phone's IP address
I work for IPinfo. What is the context mentioning us here? I'm unsure if graphene uses our data. We process trillions of requests at the moment. I have no clue which services or software even use our data, let alone identifying individual IP addresses.
Is making a connection to our API a cause for concern? If that is the case, we welcome OSS projects to user our local IP databases, which includes our free IPinfo Lite database that we primarily designed for firewall and privacy applications.
But since privacy is a major concern for them, they should just use our IP-to-country database and host an API themselves on top of it: https://ipinfo.io/lite
We are happy to support and be part of any software that want to use our data.
I agree that it would be a more privacy-friendly solution for them to host their own API, but that got me thinking, wouldn't it be possible to just let users download the IPinfo data and use it locally? Does IPinfo offer database downloads? That's also how the Server-Status Firefox extension (https://github.com/tdulcet/Server-Status) works (but it doesn't use IPinfo). Also asking for potential personal use: How does the quality of IPinfo data compare to MaxMind, DB-IP, etc?
> Also asking for potential personal use: How does the quality of IPinfo data compare to MaxMind, DB-IP, etc?
We are miles ahead of everyone in terms of accuracy. Currently, we have 1,100+ PoPs across the world running active measurements. While traditional IP geolocation services are no much more than ASN/ISP reported data aggregation and parsing services. Our priority above all is accuracy and at this moment we are likely the industry leader for that.
If you have the time, go through some of our posts in our community and you will be surprised how good our data is right now. I will share my recent favorite one:
When viewing the "Show log" screen in Netguard, under the top right, three dot menu there are checkbox options for "Show names" and "Show organization". Netguard sends requests to ipinfo.io to get information about IP addresses. These requests to ipinfo.io do not show up in the Netguard log.
There is no cause for concern necessarily. These are design choices, nothing more.
Users have no idea what happens to the data that leaves their computers. To quote from another story currently on the HN front page: "It's incredibly easy to give information away. But once that data is out there, it's nearly impossible to take back." https://news.ycombinator.com/item?id=44689059
Promises made by developers are reassuring to some, but rarely if ever legally enforceable in the event something goes wrong, and the harm already caused may be beyond redress. As a proactive measure users can, among other things, seek to minimise the amount of data they send. For example, some users might want the _option_ to stop their phones from constantly trying to ping or connect to remote servers _without any explicit user intent to do so_. Maybe they do not want their phone to act like a beacon to someone else's remote server.
The point of the comment is that sometimes there are remote connections being made to servers chosen by developers that are assumed to be OK with all users, e.g., connections to Graphene servers, IPinfo servers, or myriad other examples. Meanwhile there is no option for the user to disable this behaviour. There may be some users who prefer _zero_ remote connections except the ones they themselves choose to initiate or enable. The possibility of such users often seems to be overlooked or deliberately ignored.
Like Firefox constantly sending HTTP requests to remote servers to check for "connectivity". Even when the user is not trying to connect to any server. The requests are sent in the clear. This is not optional behaviour.
There are only a few services GrapheneOS devices connect to:
- a time server (securely, over HTTPS, not insecure NTP)
- the OS update server (obvious; it's just plain HTTP requests, no user identifiers other than the IP address, which can easily be masked by using Tor or a VPN)
- the GrapheneOS App repository, which provides updates for preinstalled apps like Auditor, as well as the Vanadium browser and WebView (it's critical to get security patches for your browser in a timely manner)
- network connectivity checks (required to sign in to public wifis that use captive portals; can be entirely disabled in the settings)
- SUPL and PSDS through GrapheneOS proxies for A-GNSS because there is no network location service enabled by default
> Can connections to Graphene servers be blocked, i.e., are these connections optional or mandatory
You can block all the connections. You don't even need to, since they can all be disabled in the settings. If you disable the System Updater app, you're gonna have to adb sideload your system updates https://grapheneos.org/usage#updates-sideloading.
> If the concern is apps that only require internet connection for ads, Netguard solves that problem without root
You don't need Netguard, GrapheneOS has a built in network permission toggle, which offers even better protection than a firewall, since it completely blocks access to the underlying network socket (https://grapheneos.org/features#network-permission-toggle)
> The user-hostile design of Android is that apps keep running in the background after they are "closed"
You can deny apps running in the background, even on stock Android. This isn't unique to Android btw, I'm sure you've come across the system tray in Windows before. Those are all apps running in the background. Android basically has the same thing, it's in the notification center, and you can also stop background apps from there.
> 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 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.
I put a Private DNS ('controld' for that matter) and never looked back. No more private VPNs with Blokada, no more block list updates. You choose if you want ad, tracker or adult blocking, without hassle, for free.
> 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.
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.
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.
I agree with you. I think FSF RYF is a pointless certification since firmware isn't going away anytime soon. I'm not a fan of their "it's part of the wiring if you can't upgrade it" compromise either since it doesn't achieve their goals and makes the situation even worse.
It would be nice if the firmware itself was free software so that it could be shipped alongside the Linux kernel, maintained indefinitely and we could customize it however we want. The hardware is supposed to do what we want it to do, not what the manufacturer lets us do.
I don't like the fact every single device out there has entirely separate computers inside them running unknown proprietary software. It feels like our operating systems aren't operating the system anymore, it's like they're just some user app sandboxed away from the real system. This presentation explains what I mean:
It's an imperfect reality. Security by isolation of devices via IOMMU addresses real concerns such as devices being able to access RAM via DMA. It's great that GrapheneOS is doing this.
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.
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.
No, someone took an out-of-context screenshot of information conveyed by the GrapheneOS account and misrepresented it. We were describing what a source we described as unreliable told us based on what they said was a leak from Google. You can see we didn't say what was claimed but rather were describing information from a source ("they said", "according to the source"). It was fully clear in the context the screenshot was taken that this was someone's speculation to us based on a leak and that we didn't consider it reliable information. Part of it turned out to be correct so we shared the information to discuss it.
Following this, we posted multiple threads correcting inaccurate claims about what we had said about this and made it clear GrapheneOS was continuing. GrapheneOS was fully ported to Android 16 before the end of June, which took longer than usual due to the changes but was still completed.
Open source drivers is a big step forward we must not discount, creating a separation between hardware trust and OS trust.
That said, to your point, both are misrepresented as fully open frequently which is just not true, and obscures efforts by teams that are working on fully open hardware solutions the hard way.
> creating a separation between hardware trust and OS trust
Typical Android devices have fully open source kernel drivers. There are usually dozens of closed source libraries in userspace such as the well known Mali GPU driver library. Closed source libraries can still be reviewed. Open source doesn't make something secure and trustworthy. It also isn't a hard requirement to review a library. Auditing a low-level C library doesn't imply finding all the vulnerabilities, particularly something hidden. Widely used open source code still has many vulnerabilities lasting for long periods of time after many people have reviewed it. It does not solve security or trust.
> That said, to your point, both are misrepresented as fully open frequently which is just not true, and obscures efforts by teams that are working on fully open hardware solutions the hard way.
A closed source SoC with open source hardware built around it and other closed source components including radios is not a fully open source computer either.
This doesn't mean it's open hardware or that it has open firmware. It has a closed source SoC and many other closed source components. Those components are closed source hardware with closed source firmware.
Snapdragon uses a fork of the open source EDK2 as their bootloader prior to the OS and publishes the source code. It doesn't mean Snapdragon is open source.
Most of the firmware has nothing to do with the boot chain leading up to the OS on the SoC.
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.
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 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.
They did not replace firmware with open alternatives. Not updating firmware is not replacing it.
> 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.
They steer people to devices with severe unpatched firmware vulnerabilities and an enormous number of severe unpatched software vulnerabilities in the case of Replicant. This is covered up and people are misled about it. These projects claiming to be focused on avoiding backdoors are in fact deliberately backdoored through not patching known vulnerabilities for ideological reasons.
> 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.
You still trust the developers of open source software and firmware. Open source doesn't result in all vulnerabilities being found, including intentional ones. It's not even close to providing it.
> This is why I reject platforms that require closed firmware in the first place to the fullest extent I can.
The platforms you're describing as having fully open firmware still have closed source firmware.
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 hardware, 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, with huge form factor and no power management. I still own one anyway because we have to start somewhere.
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.
> 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.
MNT Reform has a regular closed source ARM SoC as the main component along with a bunch of other closed source components. The chassis, board and boot chain being open doesn't make a device mostly open hardware. Anything simply using an ARM or x86_64 SoC at the core is not truly mostly open. It's a closed source system (the SoC) with open source components between it and other closed source components like radios, a display controller, SSD, etc. The same applies to other ARM and x86_64 laptops. They're built around closed source components even if the board many components go in and the boot chain is open source.
Having an open source boot chain and not requiring loading proprietary firmware from there or from the OS doesn't mean the device has open firmware. It's conflating not needing to load firmware with the firmware not existing or being open, which isn't the case.
> The Precursor is the only pocket computer platform that is maximally open hardware, 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.
This is far closer to being how you're describing other platforms. However, it does have closed source components including the FPGA and Wi-Fi. It's as close as it gets to being open hardware and that has a huge cost. Platforms simply using a closed source ARM SoC and many other closed source components are not anywhere close to being open. This is what it takes to get close, and it's not fully there.
> 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, with huge form factor and no power management. I still own one anyway because we have to start somewhere.
It's the motherboard that's open source. The IBM CPUs used with it are not open hardware.
> 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.
Laptops with a nearly completely closed source SoC / CPU are not a fully open platform, especially when it's an SoC providing most of the functionality. Talos II has a lot of functionality on their open motherboard vs. an ARM SoC with most of it on the SoC, but either way the CPU being closed source is still the most core component being closed source.
Note I described MNT reform as -mostly- open and the Precursor as -maximally- open (as in the the maximum extent currently possible to mass produce).
If Bunnis ASIC efforts succeed, then we have auditable reasonably fast chips in the next few years and a truly 100% open device. Tropic Square is another to keep an eye on.
Fully aware of everything in your descriptions here, but you always repeat this stuff as though I am not. Probably useful for others though.
Where we always seem to disagree is you usually try to dismiss mostly open solutions as no better than mostly closed as though the effort to pursue transparency is pointless. I feel every single component with open firmware and open hardware is a huge win, making accountability and community improvement possible. Likewise every blob is an eyesore that should be reverse engineered and replaced... or switch to more transparent alternatives when they exist.
Sure, auditing never catches all bugs, but it catches a -lot- of them. There are many severe security flaws I would never have had a chance in hell of having the time to find in closed binaries, let alone fixing them.
Sure underhanded C and all sorts of sneaky bugs can exist, but an open C solution could be replaced with an open Rust solution structured for east auditing or another language that makes it harder to do many common types of sneaky in.
If a vendor will not let me look at their code, I am extra suspicious of glaring backdoors or bugdoors until proven otherwise given countless examples in the wild.
I have always agreed open source alone does not mean code can be trusted. Most open source code is shit and should -not- be trusted (I review it for a living) but I am absolutely certain open source is an prerequisite to a community maintainable trustworthy solution existing where we get both freedom and security.
It's near completely closed source hardware. The SoC providing nearly the whole core system is fully closed source. An open source boot chain after the closed source early boot doesn't change this. Other components are closed source too. It's closed source with open source bits in between. Compared to the complexity of the SoC, radios, etc. the open source parts are insignificant. Open source between closed source components with most of the complexity it not mostly open source. It's simply not true.
> and the Precursor as -maximally- open
It's possible to use an open source RISC-V SoC instead of programming a CPU with a closed source FPGA. They don't use a closed source FPGA to be maximally open but rather to be closer to being able to inspect it.
> Fully aware of everything in your descriptions here, but you always repeat this stuff as though I am not. Probably useful for others though.
I don't think you're unaware of it. You must be aware the MNT Reform has a fully closed source ARM SoC with most of the core system's complexity but you still call it mostly open source.
> Where we always seem to disagree is you usually try to dismiss mostly open solutions as no better than mostly closed as though the effort to pursue transparency is pointless. I feel every single component with open firmware and open hardware is a huge win, making accountability and community improvement possible. Likewise every blob is an eyesore that should be reverse engineered and replaced... or switch to more transparent alternatives when they exist.
They are not mostly open solutions. It's false marketing. Open source does not have the properties you claim it does of heavily avoiding trust in the developers or providing much better security.
> Sure underhanded C and all sorts of sneaky bugs can exist, but an open C solution could be replaced with an open Rust solution structured for east auditing or another language that makes it harder to do many common types of sneaky in.
Memory corruption isn't required for serious subtle vulnerabilities and even safe Rust has plenty or room for memory corruption. Rust does not making auditing easy. It makes it easier than C, which is a low bar. Auditing C for deliberate vulnerabilities can easily be harder than auditing assembly code without anything that looks obfuscated.
> If a vendor will not let me look at their code, I am extra suspicious of glaring backdoors or bugdoors until proven otherwise given countless examples in the wild.
>
> I have always agreed open source alone does not mean code can be trusted. Most open source code is shit and should -not- be trusted (I review it for a living) but I am absolutely certain open source is an prerequisite to a community maintainable trustworthy solution existing where we get both freedom and security.
There are many glaring vulnerabilities in the most widely inspected open source projects including the Linux kernel. Many have persisted for not only years but decades. Open source does not inherently result in all these vulnerabilities being found and fixed, whether they were intentional or not. Open source can help with it but it provides no guarantee of better security.
Linux kernel is a typical collaborative open source project where performance, scalability and features trample over security. It being such an expansive and collaborative project means there's massive attack surface for intentional vulnerabilities and it doesn't have serious protections against it. Lack of prioritizing correctness and security for nearly all of it is pretty much equivalent to intentional vulnerabilities. Deciding not to deploy very useful features for finding / fixing vulnerabilities due to minor work it creates is typical, such as not marking intended overflows to have automatic overflow checks as an option. There's massive pushback against very basic things. The effort to introduce Rust for drivers has gone horribly despite lots of resources and it's face far greater resistance in the core kernel. Meanwhile, iOS has a kernel increasingly focused on security where they overhaul the whole thing for it. This is an example where one company controlling a project without collaborative is a massive win for security. There are projects like SQLite which don't take on the collaborative and open development aspects of open source. AOSP is similar to an extent, but heavily uses collaborative open source projects like Linux as core parts of it which largely don't have the same significant focus on security it grew over time. AOSP is about as security focused as iOS itself, but open source projects they use including Linux certainly aren't.
You keep confusing me saying open source is a -prerequisite- for maintainable freedom and security, and does nothing for security itself.
You only ever read the parts of what I say and continue to argue as though I think open source code is inherently secure, and continually ignore every time I AGREE with you that most open source code is shit.
Please listen when people are largely agreeing with you instead of hitting back with walls of text as though they are not.
MNT reform is mostly open in terms of everything but the CPU. That is a -great- start as it means fewer parties you have to trust. Also they support two different CPU vendors as well as an FPGA option soon. The CPU is a swappable component in an otherwise open platform. How can you dismiss that level of flexibility and user power as anything but substantial progress over the status quo? Please give people working hard for more freedom respecting hardware their due credit. Minimizing such very hard work will not win you allies.
Also yes, the Linux kernel is a security shit show to be sure, as well as mot desktop Linux distros, but -because- it is open I can heavily patch it and customize it to reduce attack surface.
Also because it is open projects like Asterinas can reference it to make an ABI compatible modern replacement is Rust which is making rapid progress!
Transparency is step 1 to any major progress in freedom and security and that is why I am a broken record demanding more of it from all projects widely used in high risk scenarios.
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.
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
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.
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.
An Nvidia GPU is never going to run at maximum clock speed etc on open drivers right now, but the point is if you prioritize security/privacy/freedom you have choices.
If you are not running games (which you should not on a system you need to be able to trust) maximum clock speed from a modern GPU is not needed for most workstation applications.
I generally choose AMD GPUs for the best experience with open drivers these days on systems I need high GPU performance from.
> You need proprietary microcode blobs to fix those security vulnerabilities in your CPU.
Really? Which blobs do I need on RISC-V FPGA enclaves or my PPC64le Talos II workstation which has a fully open hardware motherboard and open CPU architecture?
I make different tradeoffs on different hardware to be sure depending on the threat model of the task I am working on. x86_64 is a bit of a shit show, but you still only have to trust your CPU vendor even there, as it is possible to have FOSS firmware/software for everything else.
> PPC64le Talos II workstation which has a fully open hardware motherboard and open CPU architecture?
The ISA is open source, not the whole CPU architecture and design. There are older open core designs from IBM but that's a different thing from the more modern and powerful Power9 and Power10 CPUs.
> you still only have to trust your CPU vendor even there, as it is possible to have FOSS firmware/software for everything else
A device with assorted closed source components including as part of the motherboard itself is hardly open beyond the CPU. Open source also doesn't mean you aren't trusting those vendors. With a fully open hardware design CPU, you're still trusting that it matches the open source design and you're trusting the open source design. The manufacturing process is also generally going to be proprietary.
> generally choose AMD GPUs for the best experience with open drivers these days on systems I need high GPU performance from.
Do you count binary firmware as 'open' or not? If not, AMD is not 'open' either. If you do, Nvidia now also has open kernel drivers. Mesa developers are exploring ways to get the new Mesa Nvidia Vulkan driver (NVK) to run on top of the open Nvidia kernel driver, which should eventually make Nvidia drivers as open as AMD.
The binary firmware on an external module over a PCI bus should not have the ability to manipulate my current operating system and exfiltrate data without being noticed, but it is a non zero chance which is why on all my x86_64 workstations I run QubesOS so most hardware components are well isolated from each other with hypervisors, in addition to only open source code in my operating system and kernel layers, which is best effort today on such systems.
I generally only run gaming graphics cards on dedicated gaming machines, not on workstations I need to be able to trust. You can't use accelerated graphics in qubes anyway, specifically because graphics cards are hard to trust.
My requirements from a workstation are:
1. MUST have 100% open source code loaded in system memory
2. SHOULD have open source software in the boot trust path (coreboot/tpm2 secure boot, etc)
3. SHOULD have open hardware to the furthest extent possible that meets my use case
4. SHOULD be fully auditable and tamper evident using at-home tools and methods (like the Precursor)
> maximum clock speed from a modern GPU is not needed for most workstation applications
Well at that point buying a GPU is definitely not worth your money. You're better off using a CPU's integrated graphics unit.
> I generally choose AMD GPUs for the best experience with open drivers these days on systems I need high GPU performance from.
Yeah I agree on that, I also purchase AMD cards exclusively now.
> Which blobs do I need on RISC-V FPGA enclaves or my PPC64le Talos II workstation
I assumed we were only talking about x86. But I also believe that POWER9 CPUs don't have SSE, prove me wrong. I guess you're running Linux? I'd be very interested in looking at the output of lscpu from one of these machines.
> Well at that point buying a GPU is definitely not worth your money. You're better off using a CPU's integrated graphics unit.
Yeah I only use dead simple workstation cards or integrated graphics on my workstations, and AMD GPUs on my gaming systems which I don't trust at all (but still prefer to support companies that use open drivers)
> But I also believe that POWER9 CPUs don't have SSE, prove me wrong.
POWER9 has its own SIMD system (AltiVec/VMX/VSX) instead of SSE which is entirely its own thing. I have no idea of the performance tradeoffs here though for various use cases, as freedom is biggest factor for me.
> I'd be very interested in looking at the output of lscpu from one of these machines.
Here is an lscpu from an 8 core Blackbird though it will probably render poorly on HN.
Architecture: ppc64le
Byte Order: Little Endian
CPU(s): 32
On-line CPU(s) list: 0-31
Model name: POWER9, altivec supported
Model: 2.3 (pvr 004e 1203)
Thread(s) per core: 4
Core(s) per socket: 8
Socket(s): 1
Frequency boost: enabled
CPU(s) scaling MHz: 58%
CPU max MHz: 3800.0000
CPU min MHz: 2166.0000
Caches (sum of all):
L1d: 256 KiB (8 instances)
L1i: 256 KiB (8 instances)
L2: 4 MiB (8 instances)
L3: 80 MiB (8 instances)
NUMA:
NUMA node(s): 1
NUMA node0 CPU(s): 0-31
Vulnerabilities:
Gather data sampling: Not affected
Itlb multihit: Not affected
L1tf: Mitigation; RFI Flush, L1D private per thread
Mds: Not affected
Meltdown: Mitigation; RFI Flush, L1D private per thread
Mmio stale data: Not affected
Reg file data sampling: Not affected
Retbleed: Not affected
Spec rstack overflow: Not affected
Spec store bypass: Mitigation; Kernel entry/exit barrier (eieio)
Spectre v1: Mitigation; __user pointer sanitization, ori31 speculation b
arrier enabled
Spectre v2: Mitigation; Software count cache flush (hardware accelerated
), Software link stack flush
Srbds: Not affected
Tsx async abort: Not affected
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.
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.
> 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).
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.
No, the reason is legal. Everything, and I mean everything else is secondary. They can tell in court that they did everything what they could. Of course:
- it’s a lie
- not even a white lie, they know perfectly well, that they can do way more
- most of the security “features” are completely useless
- they also know this
However, it’s very difficult to prove these, and laymen don’t and won’t understand the details.
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.
I don't know if it has ended but you could reverse engineer the Symantec BS and convert it to regular totp. You likely need root to extract the internal store from the symantec app.
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?
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
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 :-)
> 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)
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
If it is compromised, both your passwords and TOTP are compromised, which kind of negates the point of multiple factor authentication. If they are in separate apps, hopefully both won't be compromised, at least not at the same time.
If my phone is compromised, probably neither of them are compromised, or both are. I do not see how a separate app helps. I see where you are coming from, but I think using KeepassDX for password and TOTP should work. Keep in mind you can have multiple databases, you can store the TOTP only in one of the databases.
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?
> 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.
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.
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.
Does the NextCloud app now sync contacts and calendar? Last time I tried, years ago, it did not. I use DAVx5 to sync my NextCloud contacts and calendar, via CardDav and CalDav.
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.
It is so annoying that all current smartphones are so large and heavy. The XZ1 Compact could be even smaller now considering the large case frame around the display. That would be amazing.
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.
I doubt that GOS will be able to move the needle on such a decision. But I'm also someone who'd love to have a small and more light-weight smartphone again. A smaller display of maximum 5.1 inches or so would also be in line with a sentiment of using the smartphone for its core purpose over attempting to turn it into a small PC for playing games and what not. I believe this correlates with a more secure phone.
In some keyboards (like Florisboard) there are options to either left-align or right-align the keyboard, which helps you to do that, even on a big smartphone
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 ?
> Because you said discussion are being done with an OEM, will GraphaneOS switch from pixels to a different device?
Pixels will be supported until end-of-life. Future Pixels will be supported if they continue meeting our requirements.
> 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 ?
We expect 10th gen Pixels to meet our requirements and we should be able to add support for them. It's not going to happen in 12 to 48 hours from the official launch of the devices as we did for around the Pixel 6a and later. It will be more work. We've automated most of the device support for existing Pixels now and have removed nearly all of the Android 15 QPR2 device trees rather than manually updating them. We're continuing to automate more and will use that approach for supporting new Pixels.
The devices with an OEM partner are further in the future than the Pixel 10. We need Qualcomm's new SoC with hardware memory tagging support to launch because a flagship Snapdragon is the best fit other than the current lack of hardware memory tagging. Some things need to be addressed by the OEM including licensing extra things like Qualcomm and filling in some missing features. There needs to be a clear, workable plan for updates including Linux kernel LTS branches.
I've never owned a pixel, but I'm planning on getting the pixel 10 so I can use the new android 16 Linux terminal with graphical support. I hope the pixel 10 will still fit your requirements and it won't be a hurdle to port GOS without the device tree. I see no other OEM supporting the level of virtualization with kvm and vergil Google is bringing to the pixels. Good luck!
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..
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.
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]).
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.
We use Flarum as our forum software for https://discuss.grapheneos.org/. Flarum supports viewing all of the content without JavaScript via an HTML fallback mode using pagination. Flarum simply informs people they'll have a better experience with JavaScript enabled.
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.
We're building our own fully offline implementation. Our existing implementation is semi-offline and does the position estimation locally based on downloading data kept in an in-memory cache for a limited time. We're close to what's needed for offline support already in that sense. We need to finish scraping the data and putting together a system for distributing and using it.
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.
About the OEM, are you working on having devices ship with GrapheneOS, or devices be GOS compatible (i.e. same as the Pixels)? If you're thinking of devices shipping with it, would this fix the issue of Play Integrity/SafetyNet failing? That's the main reason I am running the android on my phone, as my banks don't work with Play Integrity failing and I have to use the app for 3DS. The ability to run GOS without this issue would be huge.
>About the OEM, are you working on having devices ship with GrapheneOS, or devices be GOS compatible (i.e. same as the Pixels)?
As far as I'm aware as an outsider, the aim is a device that is compatible with GrapheneOS like the Pixels, yes.
>If you're thinking of devices shipping with it, would this fix the issue of Play Integrity/SafetyNet failing?
I think to pass this you need to be 'blessed by Google' which means being certified Android by their standards. GrapheneOS have mentioned that their CTS/CDD Android certification process holds back some of the privacy/security features (think things like new Sensors and Internet permissions etc.) implemented so they cannot can't target it.
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"
we: "that's cool, I always wanted to decrease petrol use. But... can you provide an option for some petrol use? It's called hybrid, iirc?"
vendor: "no, our requirements only support 100% electric car. Hybrid cars use petrol and we can't allow that"
we: "suuure, I get that. But the price of electricity here still hasn't come down, everyone already has personal petrol reserves, and your cars are only provided with batteries from congonese child labor mines. Can we pleeease have the half-way option so that I can use less petrol for e.g. small distance travel, but still using petrol for country-sized movement?"
vendor: "no, we only support 100% electric car. Everything smaller is outside our requirements"
Real economics would've provided competition to fullfill demand - but currently Graphene is the only well-known vendor, so complaints will keep coming
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.
> 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 table shows CalyxOS has substantial delays for important privacy and security patches. It currently doesn't provide the 2025-06-05 patch level. It's better than LineageOS and /e/OS in that regard but still reduces privacy and security through significantly delayed patches. CalyxOS also weakens parts of the privacy and security model through the privileged functionality that's added, which simply isn't covered by the comparison table.
> 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.
On Pixels, CalyxOS is missing current Android privacy/security patches. GrapheneOS doesn't support those other devices due to lack of a reasonable level of security. Each of those extra devices has significantly delayed privacy/security patches and lacks important hardware-based security features. Despite all the marketing about long term support, Fairphone 5 uses Linux 5.4 which is end-of-life in December 2025 with no plans on their part to move to a supported kernel branch afterwards. Earlier Fairphones are stuck on older end-of-life kernel branches. Those devices are missing basic updates and security protections. Those don't provide proper long term support, so if someone does have one it won't be long before it's time to buy another device.
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.
Hardware identifiers aren't accessible to user installed apps. ANDROID_ID is a per-app-per-profile random ID. Apps don't need ANDROID_ID to identify that it's the same install due to immense fingerprint surface. If you installed the app in another profile, it would have a different ANDROID_ID, but it would still potentially be able to fingerprint it as the same device based on many things like settings. GrapheneOS does have planned features to improve these things but it's not nearly as simple as making ANDROID_ID per-app-install or making the MediaDRM ID more randomized than the current per-app random value (it was meant to be like ANDROID_ID but they make a mistake that's hard to fix without breaking compatibility so we need a toggle).
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.
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.
Okay, but the danger of vendor lockout is very great because gOS only supports one brand of phone. The justification for limiting support to pixels is that it has trusted computing features, but these are made unnecessary by having a long password.
You could just have some disclaimer on the grapheneOS site that says something like "Works best with pixel phones" or have some long password requirement on non-pixel phones
It is. The idea behind using a embedded trusted computing device in this fashion is that you can store a AFU encryption/decryption keys in the trusted computing device and lower-entropy password like a 4-digit pin or biometrics, with the trusted computing device preventing a brute force attack.
But this is unnecessary if your encryption password has enough entropy in the first place, because it cannot be brute forced. This is the security model of most linux distros that use full disk encryption with LUKS. And android already lets you do this, it is just less convenient.
I use grapheneOS with a high entropy BFU password and a low entropy biometric AFU fingerprint. My linux setup works in the same way. The BFU password is the only "real" password that secures you and encrypts your data. The AFU password is a just temporary screen lock that is vulnerable to side channel attacks because the decryption keys are still in memory.
If the hardware is not done properly, then the whole thing is broken. E.g. you are useless with your encryption keys if your modem sucks and leaks data, or if the CPU can trivially be made to run custom code (and you just entered your encryption key into a software that just looks like the prompt you were looking for)
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.
Ok, fair enough, if we are looking at software side of "repairs" (updates). However I'm talking about hardware side of things - with Fairphone I can remove and replace the battery by myself (or even carry a spare if I choose to), while e.g. in the newest Pixel, 9a, the battery is glued in place.
As for the requirements, I will take your word for it. And I do appreciate that you put the emphasis on security as it is often overlooked. I guess what I'm saying is that having control over my phone (as opposed to BigTech or apps having the control) is for me a much higher priority goal than just security by itself. Hardware reparability is (again, for me) a close second.
Anyway, I hope you find a good partner for the phones, and I'm curious to see what you come up with!
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.
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.
Our hardware requirements are listed at https://grapheneos.org/faq#future-devices. There are a small subset of other devices with at least nearly all of the security features we require. However, those devices either don't allow using another OS or cripple security for it. There's no other device providing the listed security features and allowing us to support it. Pixels are also the only devices properly keeping up with current Android OS and security updates. We need ongoing firmware and driver updates. There are other devices offering support for a similar time period, but not actually providing close to the same thing during that time period.
Most OEMs do the bare minimum for security. The security features they provide are the ones provided for them by AOSP, the SoC vendor, etc. They provide delayed and quite incomplete security patches.
Android downplays the fact that it has OS releases every month. There's a new monthly, quarterly or yearly release each month. The monthly Android Security Bulletin patches are a separate thing providing backports of a subset of the security patches (most High and Critical severity AOSP patches) to older initial yearly releases (the initial releases of Android 13, 14, 15 and 16). There are also a huge amount of SoC and other hardware-related security patches with a small subset included in the Android Security Bulletin. Most OEMs struggle to provide these backports and vendor patches on time for a reasonable time period. Non-Pixel OEMs eventually update to a new initial yearly release, usually quite late, then rely on the backports to it for a year or more. Full Android security patches mean shipping the latest stable releases, which have been through significant public testing beforehand for quarterly/yearly releases and are not actually bleeding edge. Quarterly releases are as large as yearly ones but awareness of them existing is low. Android 16 QPR1 currently in Beta has more user-facing changes than Android 16.
We're working with a major Android OEM towards some of their future devices meeting our requirements and providing official GrapheneOS support. It will be their regular devices but meeting our requirements currently only Pixels do. Hopefully available in 2026 or 2027. There's no reason other devices can't provide comparable or better security than Pixels, but it's not easy or cheap.
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 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.
NFC payments work on GrapheneOS. Curve Pay works with GrapheneOS and is available in the UK And European Economic Area (EEA). PayPal launched tap-to-pay which works with GrapheneOS but has very limited regional availability. Many European banks provide working tap-to-pay with GrapheneOS.
The issue is apps banning using a device not licensing Google Mobile Services or a non-stock OS via the Play Integrity API. Google Pay does this and a lot of banks outsource tap-to-pay to Google Pay instead of providing their own like many European banks. GrapheneOS users in Europe have multiple options. Users in the US often use a smartwatch for this purpose which includes the option of Garmin Pay rather than only Apple Pay and Google Pay.
The choices depend on the region. It would be nice if the Play Integrity API was forced to permit GrapheneOS via hardware attestation verification by regulators. We're pushing for it in Europe.
- 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.
> ""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.
The company you're discussing is... GrapheneOS itself.
> GrapheneOS Foundation was created as a non-profit organization in Canada in March 2023 to handle the intake and distribution of donations. [1]
> GrapheneOS Foundation has been incorporated as a federal non-profit organization in Canada. It will be used to receive donations to pay developers and pay for infrastructure. It will also help to shield developers from attacks through the legal systems across various countries. [2]
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.
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.
The same thing could be said about any hardware. Pixels receive by far the most privacy and security research of any devices. They're by far the most secure Android devices and the only ones providing competitive security with iPhones. They're the only devices with even a reasonable level of security combined with proper alternate OS support. Our hardware requirements are listed at https://grapheneos.org/faq#future-devices. These are very reasonable requirements for industry standard security features, standard updates and the ability for GrapheneOS to use those standard security features. There are other devices with all the major features listed there but not the ability for GrapheneOS to use all of them. Updates are a major issue for all non-Pixel Android devices including the ones advertising lengthy support.
GrapheneOS is working with a major Android OEM towards their future devices providing the expected hardware-based security features and updates, unlike their current devices. The purpose of GrapheneOS is not specifically avoiding Google but if you want hardware from another large tech company to use with GrapheneOS, you'll have that option. The initial goal for these devices is providing a similar level of security and long term support to what we already have with Pixels. In the longer term, we want to have add hardware-based security features unavailable on Pixels or iPhones along with hardening below the OS layer.
For now, Pixels are the only viable option for us to use. We're actively working on changing that but we're not going to simply greatly lower our standards and support devices where we can't adequately protect users. There's no evidence of any backdoor and it's contradicted by how exploits are developed and used. There is plenty of evidence that other devices lack comparable security.
https://discuss.grapheneos.org/d/14344-cellebrite-premium-ju... shows an example where only the Pixel 6 and later / iPhone 12 and later have brute force protection which holds up against the most sophisticated company developing forensic data extraction tools. We have access to more recent documentation showing the same thing.
Why do governments buy exploit tools from NSO, Cellebrite, etc. and develop their own if they supposedly have backdoors in devices? Why would using a device from Samsung or Sony protect against it if they did?
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.
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.
The baseband firmware is not obfuscated and people can/do analyze the cellular protocol and how it functions. Which devices receive more privacy/security research than Pixels do? Which devices avoid trusting multiple companies making the hardware? Nothing. Similar things could be said about any hardware we supported, but all the other available options supporting using another OS would be far less secure and unable to provide what GrapheneOS offers. Core features would be missing elsewhere.
We're working with an OEM to have their future devices meet our requirements and provide official GrapheneOS support, but how would that change anything? It's another big tech company making devices. What do you think is special about Google and what reason is there to think they would be putting a backdoor but other companies wouldn't?
> I believe grapheneos has some sort of band band processor isolation, but I'm not sure exactly how it works.
Isolation for the radios is a standard security practice on most modern smartphones. GrapheneOS improves the security of the isolation through hardening the drivers and services against exploitation after exploiting the radio firmware.
> 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.
The CPU, GPU and many other components in laptops, desktops, tablets and smartphones are closed source hardware with closed source firmware. Wi-Fi and Bluetooth are implemented with a separate processor and operating system. There's nothing about that specific to cellular and it's a misconception that it's different from other components in this regard. Modern computers have a bunch of processors and little operating systems across a bunch of components. Many people have the wrong idea that it's somehow specific to a few things like AMD PSP, Intel ME or cellular radios when in reality that's just how things are at a hardware level across many components. Cellular radios are normally an isolated component.
Cellular can be used to detect location, but so can Wi-Fi and Bluetooth. Wi-Fi is the main way network-based location works. Most Wi-Fi networks are from ISP routers and some even have an official way for other subscribers to use it.
Cellular doesn't need to be left enabled all the time. There's airplane mode. Using cellular is an option. GrapheneOS runs on portable computers with support for Wi-Fi, USB ethernet, etc. too not onlyg cellular.
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).
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.
I believe spam detection in the Google Phone app does work on GrapheneOS.
For spam, install their sandboxed Google Play, and then install Google's Phone and Speech Recognition & Synthesis apps. For SMS/MMS/RCS spam, you'd use an app supporting blocking (e.g., Google Messages).
I imagine that Hold For Me works if you also install the Google app and whatever other dependencies.
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, but unfortunately Proton Drive, which I use for "cloud" storage, does not supported the storage API that GrapheneOS' SeedVault supports for backups
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?
Pixel 5 should only be used to preview what GrapheneOS provided prior to October 2024 when Android 15 was released and we migrated to it. It's an end-of-life device and therefore lacks driver and firmware updates. We were able to provide some of those updates past the end-of-life, but not most, and we recommend against using it. We show a notification about it being an insecure device at boot. We continued providing all of our updates and the Android updates for it until the release of Android 15, at which point we shifted to supporting it via a legacy extended support branch based on Android 14 QPR3 with backported AOSP patches and minor fixes of our own. Our support for the Pixel 5 has been winding down further since it's increasingly insecure and we don't want people to use it based on us still providing updates. A Pixel 5 works as a way to try out outdated GrapheneOS but that's about it.
Using GrapheneOS on it would be more secure than the stock OS but it's going to be quite insecure regardless of the OS so we'd recommend just not using it. The intention of our extended support prior to Android 15 and then legacy ex trended support following Android 15 was harm reduction for people unable to afford a new device yet. That's essentially over now. We just didn't remove it from the site yet to avoid complaints. It informs people that it's an insecure device at boot so it's better than people getting misled into believing the alternate OS they've put on it keeps them safe when it doesn't.
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!
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!
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.
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.
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:
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.
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.
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...
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.
Vanadium implements per-site content filtering as a usability feature via Chromium's in-built filtering engine [0]. They currently use EasyList & EasyPrivacy filters which are quite popular and also a prominent default in uBlock Origin [1].
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.
Currently all the browsers are with ads by default. Not ideal but certainly most don't encounter spyware through ads, unless they're in some spam sites.
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.
"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.
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).
> The GOS could snoop on their users and turn into malware only if it figures out that this is Rossmann's phone.
Well, yes, but not really. What you're saying could be true if the OS wasn't open source. It's not some small OS that nobody knows about. There are forks of the OS, there are other projects that selectively copy code/commits from GrapheneOS, there are security researchers who pay attention to its development. There are also people who reproduce and verify builds. It's just not possible for that kind of code to be snuck in there.
> 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.
If you pay attention to what they're responding to, you'll find that a lot of that is in response to something they said, clarification about inaccuracies in news articles, etc. The official accounts are also followed by many of the OSes' users, so some posts are for them too if certain things are being talked about in the community.
> 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).
I personally prefer quality over quantity. GrapheneOS developers take a long time to develop new features, test them, rewrite them, and it goes on and on until they have a resulting feature that is very high quality. They also have to keep in mind how much they're adding/changing so features and changes can be ported quickly when there are new upstream releases. Updating quickly is very important for security. Leaving vulnerabilities unpatched for months is not acceptable for a project and users who value security. The same can't be said of LineageOS or /e/OS. They're slow to update, roll back security, etc.
> 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).
> Other people don't think like you, they don't have to think like you.
I'm quite certain that there are more people than just me, who think that someone with close to two million subscribers on YouTube should fulfill due diligence by doing some basic research and at least read the extensive official documentation that's provided, before putting out a video with serious allegations and a very high potential of harming someone's reputation. I would go further and say that it was his intention of harming the project's reputation, but that's just my personal opinion. It's objectively clear though, that this is a very low quality video full of baseless speculation, and severely lacking any technical understanding and knowledge.
> What "absurd" claim did he put out exactly ?
His speculation about targeted malware in the OS.
This is exactly the same as going to a restaurant, having an argument with the owner, and then claiming that they might be putting poison in the food, even though there's absolutely zero evidence or anything that might indicate that, solely because you had a disagreement with someone and now want to harm their reputation.
> It's objectively clear though, that this is a very low quality video full of baseless speculation, and severely lacking any technical understanding and knowledge.
"Baseless" could not be further away from the truth. You literally have the GOS developer messages coming in live while he rehashes frivolous accusations and threatening to exposing him.
To claim objectivity, when you seem to cherry pick the parts of the video that would (loosely) fit your narrative. Where is your evidence that Rossmann is in anyway associated to harassment campaign against the project ?
> This is exactly the same as going to a restaurant, having an argument with the owner, and then claiming that they might be putting poison in the food, even though there's absolutely zero evidence or anything that might indicate that, solely because you had a disagreement with someone and now want to harm their reputation.
Damn, so close, you were almost there. A more accurate analogy you could have come up with, had you actually critically listened to Rossmann's argument in his video.
Yes, it's like going to a restaurant and having a disagreement with the cook, for the latter to explicitly threaten to harm onto you.
At that point, is it that far fetched to think he might poison the food ? When you know he has full control over the kitchen ?
You can disagree with Rossmann perception of the actual threat, but you should at least admit that it is not absurd for Rossmann to think that someone who demonstrated such irrational behavior might attempt to harm in through the means at their disposal, among which introducing malicious code. It might be unlikely given what we know about software dev, but it is not impossible, and for Rossmann, that is the only thing that matters at the end of the day.
Moreover, the GOS dev himself clearly stated he would "publicly expose him" (At 2:14 in https://youtu.be/4To-F6W1NT0?t=134 "and there will be information published about your (Rossmann) attacks on me in support of an abusive person).
Why the double standard ? That GOS dev can go around dishing out "reputational harm" but his targets doing the same is not fair game ?
At this point, Rossmann did him a service by publishing everything himself.
As far as any reputational harm is concerned, the GOS developer essentially brought it on himself. Could have dropped back when they had the fallout in September 2022, as per the chat logs (<https://www.swisstransfer.com/d/d75ff782-4a7d-4497-b04e-edd1...>) ...
> I would go further and say that it was his intention of harming the project's reputation, but that's just my personal opinion.
Sure, "harm the reputation of the project" when he was proactively giving them no string attached grants, spreading the word, and giving them an opportunities to tell their side of the story ...
> I'm quite certain that there are more people than just me, who think that someone with close to two million subscribers on YouTube should fulfill due diligence by doing some basic research and at least read the extensive official documentation that's provided, before putting out a video with serious allegations and a very high potential of harming someone's reputation.
Then in the first place, perhaps the cyber security geniuses who built a privacy and security oriented OS for smartphone could do the due diligence of gathering and presenting actual evidence of Rossmann implication in the alleged harassment campaign before before posting multiple accusatory statements across their socials media "with serious allegations and a very high potential of harming someone's reputation" ?
>> It's objectively clear though, that this is a very low quality video full of baseless speculation, and severely lacking any technical understanding and knowledge.
>"Baseless" could not be further away from the truth.
You yourself have even admitted that while it may not be true that he can be targeted, you make excuses for Rossmann saying he's a "layman when it comes to software". So, yes, it is baseless.
> it's like going to a restaurant and having a disagreement with the cook, for the latter to explicitly threaten to harm onto you. At that point, is it that far fetched to think he might poison the food ? When you know he has full control over the kitchen ?
This is a horrible metaphor because an open source project and the resulting OS is nothing like that. Better analogy would be that all the customers can watch the chef while they work, they all share the same food, and there are even cameras there for the world to see what the chef is doing in real time.
> You can disagree with Rossmann perception of the actual threat, but you should at least admit that it is not absurd for Rossmann to think that someone who demonstrated such irrational behavior might attempt to harm in through the means at their disposal, among which introducing malicious code.
If he had any integrity, he would have retracted that part of his video _at least_ when people pointed out that it wasn't true that he could be targeted. But as far as I know, he hasn't.
> Then in the first place, perhaps the cyber security geniuses who built a privacy and security oriented OS for smartphone could do the due diligence of gathering and presenting actual evidence of Rossmann implication in the alleged harassment campaign before before posting multiple accusatory statements across their socials media "with serious allegations and a very high potential of harming someone's reputation" ?
Anyone who thinks for even a moment can see what happened here. Someone tried to murder Daniel 3 times, he was upset about that and with Rossmann, he talked to Rossmann, Rossmann _records_ it as it's happening knowing full well what he was doing (which I'd argue is quite scummy), and releases the video complete with inaccuracies about the potential of being targeted. Not to mention he has a verified Kiwi Farms account, which anyone who knows the history of that site can draw their own conclusions. It's very easy to see what's all right out there in the open.
Btw I reread all the emails exchanged by Rossmann and Micay (I had already read them back when they were released, but that was over 2 years ago), and I don't see how anything Daniel Micay said would be incorrect.
Moreover, I found it quite alarming, how Rossmann addressed exactly zero of Micay's actual points, and then tried to distract from the entire situation with manipulative tactics and by trying to discredit him through his baseless assumptions about Micay's mental health.
These leaked emails don't prove anything, other than Louis Rossmann being ignorant and manipulative.
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.
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.
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.
It's not appropriate for you to be saying these things.
> 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.
This makes no sense. GrapheneOS is an open source project and anyone can look at the changes made by the project. Even the OS is reproducible and people do check that, apparently, so GrapheneOS would be caught if they were making changes. Like I even found this repository just now after a quick search https://github.com/lucasbeiler/reproducible-builds-grapheneo...
GrapheneOS isn't just some random OS that nobody has heard of. There are lots of eyes on it, so sneaking some backdoor into the OS would be very difficult and extremely stupid. One misstep and the project would be gone. Do you really think Rossmann is worth that? I don't.
> 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.
I've already pointed out in other comments that he had no good reason to fear a targeted update. It's just not possible. He should know that by now, but as far as I know he has never retracted that part of his video.
> 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.
There are a couple of comments in response to my own saying basically the same thing, so I'll do the same...
Rossmann shouldn't be excused for making his harassment video about Daniel because he doesn't understand how things work. Anyone who bothers to think about it for a moment would understand that someone who had been swatted 3 times by a crazy person spamming community chat rooms with illegal content would be extremely upset. Someone tried to _murder him_ and was trying to destroy the project, and then this video comes out leaking a private chat, and Rossmann portrays him as crazy? Rossmann knew what was happening and then his first thought was to start recording? How is that justifiable?
You confessed you are a Rossmann fan in another comment, but even a fan should be able to see what had gone on here...
> Expecting a layman to know that is not reasonable.
And you are defending the inaccuracy in his video saying he's afraid of being targeted when it's not even possible, and your excuse for him is that he doesn't understand. There is no excuse for his video in the first place, but to also add this falsehood that he even can be targeted is extremely damaging for a project prioritizing privacy and security. And yet even though I'm sure he knows this now, as far as I know he hasn't retracted what he said. I don't think he cares about accuracy. Among other things, he's a YouTuber and he got views and attention, so I guess he got what he wanted at the expense of someone else during an extremely trying time. I don't think that's justifiable, I think it's scummy.
> If anything, even after that video, he kept recommending GOS whenever he talked about privacy.
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).
There are a couple of comments in response to my own saying basically the same thing, so I'll do the same...
Rossmann shouldn't be excused for making his harassment video about Daniel because he doesn't understand how things work. Anyone who bothers to think about it for a moment would understand that someone who had been swatted 3 times by a crazy person spamming community chat rooms with illegal content would be extremely upset. Someone tried to _murder him_ and was trying to destroy the project, and then this video comes out leaking a private chat, and Rossmann portrays him as crazy? Rossmann knew what was happening and then his first thought was to start recording? How is that justifiable?
You confessed you are a Rossmann fan in another comment, but even a fan should be able to see what had gone on here...
And you are defending the inaccuracy in his video saying he's afraid of being targeted when it's not even possible, and your excuse for him is that he doesn't understand. There is no excuse for his video in the first place, but to also add this falsehood that he even can be targeted is extremely damaging for a project prioritizing privacy and security. And yet even though I'm sure he knows this now, as far as I know he hasn't retracted what he said. I don't think he cares about accuracy. Among other things, he's a YouTuber and he got views and attention, so I guess he got what he wanted at the expense of someone else during an extremely trying time. I don't think that's justifiable, I think it's scummy.
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.
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.
As best I can tell, you've done nothing more than brigade a thread with odd claims about the GOS developer, sourcing from an interaction with a known drama YouTuber/KiwiFarms associate.
The people you've had respond to you in this thread, who likely have more intimate knowledge of what actually happened, have done a better job of breaking down this stuff - so I'll just defer to them.
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.
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.
> Our community manager has provided a response to the recent LWN article on GrapheneOS with important corrections and context.The article had significant inaccuracies about the history of GrapheneOS, our organization and the details of what we provide.[.................]
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.
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!
Really feel a similar sentiment to a lot of others in the comments! I'm enjoying the recommendations other shared here. I _think_ this follows the rules of conduct for HN but let me know, I recently brained dumped about the following on my blog about the general experience setting up GrapheneOS: https://blog.matthewbrunelle.com/i-picked-a-really-weird-tim...
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.
The submission is a bit old but let me try anyway since I see some user claiming to be Graphene community manager here. Let me first reiterate that GOS is an amazing project and that I am super grateful for your work. That said, I think the #1 missing feature is the lack of a robust backup solution. Las time I checked, there was an ongoing discussion about shipping an ad-hoc backup system for GOS. ANy uodate on this? Thanks!
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.
> Although it is conterintuitive to use a Google device to get away from Google
The purpose of GrapheneOS is privacy and security, not specifically avoiding Google, which is not what privacy is about overall. Many companies including Android OEMs have worse privacy practices.
> Just stay out of the radar of the leadership, they can be a bit abrasive, for the lack of a better expression.
There are a lot of ongoing attacks on the GrapheneOS project and our team including through fabricated stories and spin. People should look into the actual verifiable facts and look at who is being targeted with harassment and bullying. We defend ourselves from this including debunking inaccurate claims about the project and our team.
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'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.
Fairphones lack proper security patches and OS updates from day one. /e/OS makes this substantially worse compared to Fairphone's own OS. Fairphone tends to lag 1-2 months behind on Android's standard partial security backports and a year or more behind on yearly OS updates. They skip the monthly and quarterly releases. Fairphone 5 uses the Linux 5.4 LTS branch which will be end-of-life in December 2025 with no plan to move away. Older Fairphones use end-of-life kernel branches.
Here's information from the author of the divested projects about /e/OS including data on updates from 2021 up until late 2024:
For the Chromium update summary from July 2024, note 128/135 was shipping each update on a given update path. /e/OS only shipped 12/135. They did not ship most Chromium security updates and skipped most releases. They're still skipping many releases and have significant delays for the ones they do ship.
Here's an article from another privacy/security researcher on /e/OS covering some of these issues:
As documented there, /e/OS has their own invasive services including user tracking in the update client. https://community.e.foundation/t/voice-to-text-feature-using... is another example where /e/OS sends user data to OpenAI without consent for speech-to-text compared to Apple doing it locally by default and Google at least supporting doing it locally and encouraging enabling it.
There's a third party comparison table at https://eylenburg.github.io/android_comparison.htm with a privacy and security focus. It doesn't currently cover invasive services added by operating systems or privacy/security regressions beyond patch delays though. It covers what is done with most of the standard AOSP services and how Google service compatibility is handled.
> 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.
The purpose of GrapheneOS is providing a high level of privacy and security. This requires secure hardware/firmware with important hardware-based security features and driver/firmware patches. Using a Fairphone with /e/OS is nearly the direct opposite of GrapheneOS.
> Alternatively, there is the iPhone but I do like fdroid and the more open nature of android.
An iPhone would be a far better choice for privacy and security than anything with /e/OS.
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
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.
> 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!
Android has a standard system back navigation gesture based on the previous system back button. Apps integrate support for it. Chromium disables their back/forward gestures when using the modern gesture navigation in the OS. It would have made sense to have a forward gesture but Android never had that as something apps had to implement so it would only work in a small subset of apps and would be generally unavailable, which would be confusing.
Phone app has a button for ending the call. It's our fork of AOSP Dialer with minor changes including UI improvements. Calculator, Clock, Contacts, Gallery, Keyboard, Messaging and Phone are AOSP apps which we need to overhaul or replace. These look and function the same way Google's apps used to but are outdated. They're the open source projects which were abandoned beyond security patches after they forked them off into their own proprietary Google apps. Gallery and Keyboard will likely be replaced while the rest will be overhauled. We know these apps have a bad UI but our focus has been on the core OS instead of apps people can replace. We're beginning to do more work overhauling these.
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.
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.
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.
Battery life improved a lot with the 9th gen Pixels other than the Pixel 9a due to the dramatically more efficient cellular radio. Set it to "4G" or the GrapheneOS added "4G only" as the cellular network mode and you should save a lot of battery life compared to having 5G enabled all the time. Battery life heavily depends on the apps, network and overall configuration. It's easy to end up with bad battery life with lots of apps doing their own push, etc.
GrapheneOS users tend to avoid using Google services when possible and this has a battery life cost when using apps like Signal with their own push systems. In the case of Signal, Molly is a fork with UnifiedPush support that's more efficient but it requires running a server to convert FCM to UnifiedPush since Signal doesn't support it.
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.
> Phones -are- optional and if you think otherwise you might be an addict.
Smartphones are small portable computers. You're using a similar computer to make posts on social media platforms including Hacker News.
> It is better in one way: a reasonably stable person holds the keys to the kingdom.
Repeatedly claiming that I'm insane, schizophrenic, delusional, etc. is not a reasonable criticism of GrapheneOS. I'm clearly none of those things. I've been targeted with attacks including harassment and tons of fabricated stories for years beginning with my former business partner and his associates. You thoroughly discredit yourself by going as far as baselessly claiming that I'm schizophrenic because you don't like the way I've tried to defend myself from these attacks.
The lead developer of CalyxOS (cdesai) was a Copperhead employee directly involved in the 2018 takeover attempt on GrapheneOS. CalyxOS itself directly originates from the takeover attempt on GrapheneOS. The people involved demonstrated their lack of ethics through their participation in the attacks on GrapheneOS and partnerships with people involved in it. You've been attacking us for years alongside them. CalyxOS exists because of this takeover attempt. It's a non-hardened OS which was created by heavily using GrapheneOS source code and documentation without most of our privacy and security features.
I am not qualified to actually diagnose you with anything, but I think you are brilliant with normally well reasoned threat modeling, yet also you seem stuck in a revisionist history narrative that people were trying to rip off or steal from GrapheneOS, when I was there for a lot of it, in frequent contact with all main parties involved. The other projects simply existed with different goals that sometimes referenced or forked code you chose to open source (which everyone appreciates). The Copperhead shady licensing situation as I understand was understandable to walk away from, but the constant citing of conspiracies and sock-puppet campaigns that never happened and your hostility to CalyxOS, F-Droid and others who are good community actors was where a lot of people including me felt you lost the plot and were not being rational. The "takeover attempt" narrative never happened and every time you say it did without evidence you hurt your credibility. It is an incredible conspiracy accusation that merits proof, or you will continue to be called delusional. I do always make an effort to separate these seemingly irrational views with otherwise well reasoned security engineering work.
The primary thing we disagree on in a pure objective security engineering capacity is you feel it reasonable that a single person, you, can be trusted to resist coercion or manipulation to hold the signing keys that would allow pushing any code to the phones of a lot of highly targeted and vulnerable individuals. Otherwise I actually normally agree GrapheneOS has made the best effort defense calls it can in a very broken and proprietary ecosystem. Use open stuff where you can and where you can't try to put up IOMMU walls. I get and respect the pragmatism here. I do similar in AirgapOS and other projects.
I however absolutely can never recommend trusting centralized/proprietary software supply chains in areas where dramatically more open and accountable solutions already exist, which is why I do not actually use or recommend CalyxOS or GrapheneOS for high risk use cases and instead full source bootstrapped a Linux distribution from scratch that avoids any trust in me as the founder by design.
For low risk use cases where users simply don't trust Google or the stock phone malware, LineageOS or CalyxOS is just fine as they remove this, and I am more inclined to support cdesia/CalyxOS which at least attempts basic signing, and trust cdesia as a keyholder when someone really wants to use Android purely because of his peace-keeping personality that is normally very receptive to criticism, and is never hostile to anyone that forks their code for use in other projects as you have a history of doing, but ultimately again, I don't actually use or recommend CalyxOS or GrapheneOS for most people for most use cases.
If forced to use a mobile device again I would probably fork GrapheneOS, remove all the proprietary bits I can, LTE, bluetooth, etc be damned, and sign it myself only for my own use, until I could develop an quorum enclave controlled signing scheme and then offer that.
If you were to agree to take on quorum controlled signing of reproducible builds, then there is no central trust in you, and all my primary arguments against GrapheneOS go away and GrahpheneOS would be leaps and bounds better than CalyxOS by any technical measure I am aware of.
If you put aside any dislike of me, objectively, removing trust in a single person makes you and the project and users safer, and make it much easier for people to separate your personal views from the stability of the project as a whole.
I could get dementia tomorrow and I am confident the StageX project would continue without me with signatures by other maintainers by design. The team already has made several releases without needing signatures from my key already. This is a proven strategy now, not just a theory I parrot to try to win arguments.
GrapheneOS, for all its high risk users, deserves to be protected from the failing of any one human or build machine.
I'll let you have the last reply as this will go on forever otherwise. You know how to contact me if you ever want to discuss any of this privately.
> I am not qualified to actually diagnose you with anything
You should stop calling be insane, delusional, etc. It's quite easy to stop.
> yet also you seem stuck in a revisionist history narrative that people were trying to rip off or steal from GrapheneOS
No, I'm not doing that. The fact that they built on our code while trying to undermine us with misinformation and numerous forms of attacks is what makes it wrong. Calyx knowingly spread and supported misinformation about GrapheneOS and myself. They welcomed, tolerated and worked with people involved in harassment along with frequently participating in it. You do it yourself as you've demonstrated here so of course you don't see it for what it is or think it's wrong.
> but the constant citing of conspiracies and sock-puppet campaigns that never happened
The harassment and their involvement in it happened and continues to happen. Your involvement in it is real and continues too. There's no conspiracy. It's plain for all to see you repeatedly calling me insane, delusional, schizophrenic, etc. and personally targeting me in similar ways over and over. You're just one of many people doing it. That is the harassment, which clearly does exist and you participate in it including in this thread. Calyx and their community are heavily involved in it.
> your hostility to CalyxOS, F-Droid and others who are good community actors
CalyxOS and F-Droid both have multiple people who were involved in the takeover attempt and supported their attacks on us, including the lead developers of both projects.
> a lot of people including me felt you lost the plot and were not being rational
It's factual information, and it's you not being rational about it.
> The "takeover attempt" narrative never happened and every time you say it did without evidence you hurt your credibility
It is exactly what happened. My former business partner tried to take over my open source project against the terms of our agreements. The project was started prior to the company existing in late 2015 and was very clearly separate from it. This has been confirmed by other people involved and around at the time including the 3rd person involved in forming the company.
> It is an incredible conspiracy accusation that merits proof, or you will continue to be called delusional
My former business partner trying to take over my open source project is what happened and is not a conspiracy theory or delusion.
> I do always make an effort to separate these seemingly irrational views with otherwise well reasoned security engineering work.
My statements and views about this are not irrational.
> The primary thing we disagree on in a pure objective security engineering capacity is you feel it reasonable that a single person, you, can be trusted to resist coercion or manipulation to hold the signing keys that would allow pushing any code to the phones of a lot of highly targeted and vulnerable individuals.
We don't disagree on the concept that it would be nice to avoid trusting a single person with this. Where we disagree is that I do not think your proposed approaches are better or that they actually address the trust placed in many people.
> and I am more inclined to support cdesia/CalyxOS which at least attempts basic signing
Not clear how you think we do not do basic signing.
> and trust cdesia as a keyholder when someone really wants to use Android purely because of his peace-keeping personality
He was directly involved in the very real takeover attempt on the GrapheneOS project at Copperhead. He stood by as Nick repeatedly spread misinformation about GrapheneOS and personally attacked me including regularly covering it up. He has a long history of making false claims about GrapheneOS and myself himself. He's friends with many people participating in harassment towards me and clearly has no issue with it along with openly helping them do it.
> that is normally very receptive to criticism
In reality, no, and they'll quickly shut down conversations particularly involving any of this. You think they'd talk openly about this where someone raises actual things they've done and participated in? No.
> and is never hostile to anyone that forks their code for use in other projects as you have a history of doing
Calyx gained influence over Seedvault, a project written for GrapheneOS by a GrapheneOS user, and has since used that to be hostile towards our users reporting issues there and us for continuing to reluctantly use a project now hostile towards us. They've done the same with other projects. They're hostile towards our users, not only us.
A Calyx contractor recently closed a valid F-Droid bug filed by a GrapheneOS user causing it to wrongly show a warning on GrapheneOS every time it installs/updates an app. It's clearly an F-Droid bug since we use standard Android infrastructure to add our Sensors permission and their bug occurs with the POST_NOTIFICATIONS permission and multiple other past cases of added or split permissions in Android. It's a long term F-Droid bug which has existed for ages. Instead of fixing it, they're keeping incorrect code with no purpose and instead adding workarounds for specific cases found to occur with Android's added or split permissions. There's no reason for F-Droid to be checking that the requested permissions parsed from the APK by them match what the OS considers to be the requested permissions. The APK is verified before it's installed and F-Droid's understanding of permissions not matching Android's understanding is fully expected since it does not handle implementation details. It cannot properly handle it as the OS does because the OS adds and splits permissions this way in future releases, so adding all of the current ones still causes it to break in the future. This used to break automatic updates for GrapheneOS users, but at least now it only displays an incorrect warning. They may change it to break things again. Meanwhile, they falsely claimed we were avoiding doing something about this to hinder F-Droid's compatibility with GrapheneOS when they are blatantly doing that. This is one example of how they misuse their control over projects to cause harm to their own users to hurt GrapheneOS. They've done so repeatedly.
> If you were to agree to take on quorum controlled signing of reproducible builds, then there is no central trust in you, and all my primary arguments against GrapheneOS go away and GrahpheneOS would be leaps and bounds better than CalyxOS by any technical measure I am aware of.
The whole thing is a personal grudge and you hold us to a standard you don't hold other projects to based on it. A substantial amount of resources is required to simply make 1 set of builds. Blocking releases indefinitely any time there's a regression in determinism without any more resources to deal with that or early access to address issues prior to when a stable release comes out isn't going to work. When we're porting to a new release like Android 16, addressing some kind of new bug causing something to be non-deterministic cannot be our priority without early access to the release and resources to handle it. If you truly wanted us to do this then you could have helped us get what we needed to do it, make the required scripts and improve protection against non-determinism getting introduced. Instead you act as if this isn't something we want, when it is, but we aren't willing to break updates with an improper implementation.
It's not clear how you avoid trusting me or the developers doing nearly all of the actual development and code review on GrapheneOS through this though. Reproducible builds combined with checking it's reproducible from other parties does not truly accomplish that. Source code is being trusted either way.
There is someone actively reproducing each of our builds after we make releases. It's fully reproducible but AOSP and other projects do have upstream regressions for this we have to fix on a regular basis. It's not always easy to fix.
> If you put aside any dislike of me, objectively, removing trust in a single person makes you and the project and users safer, and make it much easier for people to separate your personal views from the stability of the project as a whole.
I dislike your false claims about me and your harassment towards me. Most of the few times I've interacted with you for several years have involved you making personal attacks on me and talking about us not providing a reproducible build verification feature which barely any projects provide and which is not practical for a project largely based on AOSP without early access or the resources to fix all reproducibility issues they introduce prior to stable releases.
> I'll let you have the last reply as this will go on forever otherwise. You know how to contact me if you ever want to discuss any of this privately.
I don't think we're ever going to come to an understanding. I simply want you to stop making public personal attacks on me. I'm not showing up in threads about your projects talking about what you've done towards me, but you keep showing up in discussions about GrapheneOS to claim that I'm crazy and delusional. You're doing the opposite of encouraging us to implement the signing feature you want.
I was referring to CalyxOS doing signing over LineageOS which does not (in any useful way), as the two popular operating systems that happen to share a lot of hardware compatibility overlay with GrapheneOS (but admittedly little else in common).
The one point I will take that is fair is to stop trying to diagnose you as that is not my background or place to do. We will likely continue to have wildly different accounting of the same events and the motivations of those involved, but it is on me to not lower my communication standards when dealing with people I find to be extra difficult or extra wrong. Point taken.
I apologize for any and all assumed medical diagnosis related comments about you and I commit to stop making these as I am not qualified to make them. I will also discourage those comments in my communities as I can. We should be better than that.
What I can and will repeatedly say is that you are obsessively defensive about GrapheneOS to the point that all criticism of it or your communication style or use of your code in related projects is regarded as a coordinated attack or harassment campaign when it is simply a lot of people who have independently found your personality impossible to work with in spite of making useful code. So much so that many have taken steps to actively fork things away from you so they do not have to deal with you because your approach puts -their- mental health and desire to work on related code at risk.
This is a real shame things went this way, because so few doing hard and important security work also have strong interpersonal skills.
I am going to try to do better here, and I hope you do the same. It is unlikely we ever be friends but I hope we reach a point where we can make use of ideas or code each other might have been involved in without drama. I am even considering adding hardened_malloc as an optional package in stagex because I still feel this is great work.
I will stay out of threads on your projects unless about something I am actively working on or working with, but I will continue to share my own view of shared events and my issues with trust structures in current Android efforts, including GrapheneOS and your leadership style, when they come up organically by others in my communities.
I hope you are able to take that for the win that it is.
> 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?
CalyxOS lacks the current driver/firmware patches and isn't a hardened OS with similar privacy and security patches. There are plenty of worse options but people are better off using an iPhone.
Hardware and firmware is closed source in general and the complexity of that dwarfs a few dozen closed source driver libraries used on top of open source kernel drivers. Pixels have those libraries built with debug symbols and they're not hard to review. It's not obfuscated code and you're given the function names, etc.
Those few dozen mostly quite small libraries being open source instead of closed source with debug symbols would be nice and is something we want. With an OEM partnership, we can have access to the sources and build them with hardening even without those being open source yet. We can likely include debug symbols just as Google did for the most part on Snapdragon Pixels. Convincing a company like Qualcomm to open source those would be ideal, but it's far from being at the top of a rational list of privacy and security improvements which could be made.
> This does not make sense at all.
You can see he's once again making a baseless claim that I'm schizophrenic, delusional, etc. in his post here as he has done many times before. There's also the baseless claim that I believe wild conspiracy theories. It's not me making unsubstantiated claims about backdoors and proposing approaches to prevent it which disregard the hardware and firmware to focus on the OS having reproducible builds, which would not stop malicious changes hidden at a source code level. I don't think Hacker News should permit baselessly claiming someone is schizophrenic. It's not reasonable discourse, and neither is linking what's clearly harassment content from a Kiwi Farms as happens here regularly. I've never claimed GrapheneOS prevents hypothetical backdoors and certainly wouldn't claim reproducible builds (which we have) can somehow we used to prevent it for the OS.
We can make more use of the reproducible builds but enforcing anything based on it requires early access and more resources to fix reproducibility issues early to avoid delaying security updates. It will not avoid trust in the OS developers and the projects it uses itself. It can only reduce trust in the build infrastructure and people involved. Open source does not prevent backdoors. The small amount of closed source library code for supporting a modern smartphone SoC, etc. is also quite insignificant compared to the overall hardware and firmware complexity. Reviewing those libraries is also quite doable. Open source is not a hard requirement to review something, particularly with debug builds for most of it and no obfuscation. When we find bugs in this code with MTE, we get nice tracebacks with the function names due to the debug symbols. It's hard for us to make our own fixes for it, but not impossible. We would prefer if they were open source, but it's FAR from the most pressing issue and is something SoC vendors could quickly solve if convinced to do so.
> 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.
> Also, you are pretty much factually wrong on a bunch of items on your list.
If you are going to call me misinformed, please take the time to prove it so I can stop sharing information I otherwise have no reason to believe is incorrect.
> There is no 100% open-source hardware, period.
Multiple fully or mostly open hardware computers exist. They just cannot run android.
MNT Reform, Precursor, and Talos II are the top three that come to mind.
Those are lightyears ahead in openess and auditability compared to anything Google produces.
> Multiple fully or mostly open hardware computers exist. They just cannot run android.
No, not really, and there's no reason those can't run AOSP.
> MNT Reform
It has a typical closed source ARM SoC and other components. The chassis and board being open doesn't make all the components open. CPU, GPU, MMU, USB, etc. are provided by the SoC and are closed source as usual. It has closed source hardware and firmware for the SoC along with other closed source hardware and firmware. Not having to load firmware from the OS does not mean it's open hardware and firmware. It's barely more open than other computers for the most complex parts of it.
How is something fully open hardware if the vast majority of the complexity is in closed source components providing most of the functionality? The SoC is just the most complex of these by far.
Why couldn't AOSP be run on a regular ARM SoC used in devices which run AOSP? AOSP works fine on top of the mainline Linux kernel and drivers.
> Talos II
A mostly open source motherboard where you drop in a closed source CPU is not really an open source platform. It's not fully open source itself and the CPUs used with it are not open source. IBM took steps towards open sourcing PowerPC as an ISA and relatively primitive open source cores OpenPOWER core designs exist. However, what's actually available and used with it are closed source CPUs. In theory, there can be open design CPUs for use with it. As a motherboard, it's pretty close to fully open hardware. As a functioning computer, it's mostly not because a motherboard is not a whole computer and is far less complex than the CPU even with a more traditional desktop design with less functionality moved into an SoC.
> Precursor
It has a closed source FPGA as the primary processor and other closed source components. It's far closer to being open source, but it isn't fully open hardware. This is the only one you listed which is anywhere close to mostly open source. It is very far from a powerful modern smartphone device though.
> Those are lightyears ahead in openess and auditability compared to anything Google produces.
The primary SoC in each is closed source. Precursor programs their CPU on top of that closed source FPGA so the CPU is open source in that sense and much closer to being mostly open. It's not the only closed source part of it.
The other 2 examples have a closed source SoC. One uses a regular closed source ARM SoC incorporating far more than a CPU and GPU into the closed source chip. The other depends on a more traditional desktop style closed source CPU from IBM outsourcing more to the motherboard.
> GrapheneOS (like all modern AOSP based ROMS) can literally not function with just the open source code.
It does not inherently require any closed source code or hardware. Real world hardware is closed source and requires tons of closed source firmware. Not updating the firmware doesn't make it not exist. It would mean it was outdated and missing important security patches. Lots of firmware is updated by GrapheneOS. All of the kernel drivers are open source. Replacing closed source libraries such as the Mali GPU library to use hardware components is something relevant to GrapheneOS and any other OS targeting the same hardware. It's best for the SoC vendor and OEM to be involved in that rather than spending many years gradually assembling it downstream where by the time things work, the device is end-of-life. The hardware/firmware would still be just as closed source after doing all of that.
Ignoring all of our hardware requirements would not result in there being a single device we could support without nearly entirely closed source hardware and firmware.
> He is without question a brilliant security engineer, but we can't ignore his very public Terry-Davis-esqe history of mental illness.
There's no basis for these repeated claims that I'm insane, delusional or schizophrenic. Defending myself from frequent attacks by many people doing exactly what you're doing doesn't make me crazy or an aggressor towards the people doing it. You're demonstrating the ongoing libel, harassment and bullying directed towards me. There's no point in claiming it's a delusional when you've repeatedly engaged in it. Engaging in this in plain sight and pretending it's imagined is ridiculous.
> 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 do not believe any wild conspiracy theories. It's a baseless and dishonest claim. I'm not the one pushing unsubstantiated claims about backdoors and a clearly non-working approach to preventing them. Not having the Mali GPU driver library and similar closed source userspace libraries would not change that the hardware and firmware is closed source and also far more complex.
> 1. they are able to find a device they can run 100% open source code on with no binary blobs
There's no laptop, desktop, tablet or smartphone which is not filled with closed source hardware and firmware. Having some closed source libraries for a Mali GPU driver, etc. which are not obfuscated, generally have debug symbols and can be thoroughly inspected/audited if you want to do that is insignificant compared to the vast complexity of the closed source hardware/firmware.
A device avoiding having a few dozen closed source vendor libraries would be nice but it's still going to be closed source hardware and firmware. It would allow us to cover it with our added compiler-based hardening and much more easily fix or work around bugs we find with our hardening features such as memory tagging. It's something we want and can eventually be a requirement, but not yet. Tensor Pixels greatly reduced how much of this there is compared to Snapdragon Pixels but didn't keep going in that direction especially with Android 16 throwing away a lot of progress.
> 2. The ROM can be full source bootstrapped to mitigate trusting trust attacks.
It's an operating system, not a ROM. Having a standard toolchain build is for reproducible builds and all parts of the toolchain itself can be built from the source tree.
> 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.
GrapheneOS has reproducible builds. There's a community member regularly testing it and publicly reporting any issues which come up in our public development room. A recent example is that Android 16 split up the kernels into 3 groups which we found hard to explain and make sensible for people building it, which they ran into. There are sometimes regressions in AOSP which cause minor reproducibility issues. This community member looks into those to determine what's wrong. There are not currently any known build reproducibility issues which occur regularly. There's no strong commitment from the Linux kernel, AOSP, Chromium, etc. to keeping builds fully reproducible and blocking security updates based on this wouldn't make much sense, particularly with a strict interpretation of it rather than investigating the actual differences and determining if it's even an actual code difference.
AOSP having a regression causing a timestamp to be added somewhere isn't a reasonable justification for blocking security updates. No system without the ability to investigate the cause and determine if it's okay would be reasonable. We would need to finally have early access to new Android releases to test this in advance and have fixes ready to go prior to the stable releases. We do not currently have this early access but will likely obtain it from the OEM we're working with soon. We would still need additional resources to have ongoing testing for this and fixes for any relevant regression that finds. Porting to new releases prior to them being stable and specifically testing this would be needed.
We can't risk introducing a very a fragile system which could result in substantially delayed updates. Our plan for reproducible builds is to provide an opt-in feature where people can select which additional parties they trust to reproduce builds without falling behind significantly. This would solely be for the OS update client and App Store updates. It would not be for other uses of signing such as verified boot which are not designed to handle this. It would a system to verify that signed hashes from other parties have been published for an update. The meaning of that can be defined by these parties reproducing builds, such as how they'll investigate a mismatch and the way they'll determine if it's an issue.
In practice, this would be based on tools we publish for others to use for building and comparing. Similar to the rest, people are trusting the source code and the people who wrote it. Source code is not inherently trustworthy and provides no magical privacy or security properties. Reading the sources does not mean you will find all the vulnerabilities, particularly subtle ones or hidden ones. It clearly doesn't provide that even for extensive audits/review. Why does the Linux kernel have so many serious vulnerabilities being found on a regular basis including ones which are years and even decades old if this approach works?
If you truly believe that I'm insane, why do you think it's reasonable to use code that I wrote or supervise writing as long as the build matches the sources?
> 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.
You use many open source projects with far fewer review. GrapheneOS itself is based on AOSP which uses a huge number of open source projects from a huge number of people. The Linux kernel alone has a massive number of contributors and most code has little review. It's filled with vulnerabilities which are found regularly. https://lore.kernel.org/linux-cve-announce/ provides a very flawed overview of this based on what is backported. These devices are compromised in the real world by exploiting vulnerabilities like many of these. Reproducible builds and checking that others have reproduced builds is not actually going to stop a software supply chain attack in practice, which would work within the constraints and use source code. If one of the projects used by AOSP has a backdoor added to the sources, how do reproducible builds help? We'd just be building the code and the backdoor would be reproducible.
> 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.
Computers have closed source hardware and firmware in general. A few small closed source libraries are not significant compared to the overall complexity of the closed source hardware and firmware. Those libraries are easy enough to review. Pixels have debug symbols enabled for them. Reviewing firmware is a larger scale and much harder undertaking. How do you review the hardware itself? Even if the hardware design was fully open source for the SoC including the CPUs, GPUs, MMU and everything else along with the radios and other peripherals, how would you verify that what a chip manufacturer like TSMC produced matches the hardware design?
> 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.
The lead developer of CalyxOS is a former Copperhead employee directly involved in the takeover attempt on GrapheneOS in 2018. You're talking about someone who was a direct participant in doing shady things for Copperhead's CEO going against the ethics of the open source project the company was meant to be supporting including participating in the takeover attempt and then leaving following it.
He was involved in subsequent attacks on GrapheneOS including similar harassment to what you participate in yourself. CalyxOS does not have current Android privacy/security patches. It's still missing the June 2025 patches for Pixel drivers/firmware. It isn't a hardened OS like GrapheneOS with similar privacy or security improvements, and it doesn't maintain all of the standard security model due to the privileged code they add to the OS.
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.
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?
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.
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.
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".
I've got a Pixel 9a expected to arrive today, specifically for it to run GrapheneOS. One of my old phones was a Nexus 6P running CopperheadOS (prior to the dispute that spawned GrapheneOS), and it was great back then. Looking forward to how things have progressed in the years since.
I wish GrapheneOS would support non-Pixel hardware, though, specifically my Fairphone 4. I get why that probably won't ever happen, but it feels like a massive regression in terms of repairable hardware to move away from that.
"Great to have Google kicked off the phone"
Except the default browser is Chromium with some changes
This reminds me of a recent HN comment I saw that suggested using Firefox was "kicking Google where it hurts" or something like that
Like Firefox, this project depends on Google. For the hardware, the web browser and who knows what else
It even offers a sandboxed Google Play Store
It tries to copy Google paternalism
It swaps a Google mothership for a Graphene mothership
What if the computer owner does not want a mothership
Can connections to Graphene servers be blocked, i.e., are these connections optional or mandatory
Even Netguard which works on any hardware and does not require root makes unnecessary connections to ipinfo.io servers effectively giving them a list of almost every domain the user's phone trying to access
If the concern is apps that only require internet connection for ads, Netguard solves that problem without root
Most apps but not all will try to connect to the internet at some point, even if you never use them
The user-hostile design of Android is that apps keep running in the background after they are "closed"
(There are crude apps one can use to automate manually killing each process with "Force stop" but no one uses them. This doesn't prevent apps from trying to access the internet on some preset schedule)
Netguard will show when apps try to connect and block the connections. It provides DNS logs and PCAPs.
One does not even need Netguard to see this subversive activity
Try this at home
Enable IP forwarding on a computer you can control, i.e., one that is running an OS you can compile yourself such as Linux or BSD
Put the phone on the same network as this computer
Set the phone's gateway address to the address of the computer
Run tcpdump on the computer and filter for the phone's IP address
I work for IPinfo. What is the context mentioning us here? I'm unsure if graphene uses our data. We process trillions of requests at the moment. I have no clue which services or software even use our data, let alone identifying individual IP addresses.
Is making a connection to our API a cause for concern? If that is the case, we welcome OSS projects to user our local IP databases, which includes our free IPinfo Lite database that we primarily designed for firewall and privacy applications.
I think they were talking about the Netguard app (not a part of GrapheneOS or anything) using IPinfo.
GrapheneOS definitely doesn't use it. It doesn't contact any third-party APIs. Everything is well documented: https://grapheneos.org/faq#default-connections
Thank you for sharing the info.
In both cases, they could opt to download our database locally and use it through their own API system.
We sponsor the AlmaLinux Foundation through a data sponsorship for their mirroring system: https://almalinux.org/blog/2024-08-07-mirrors-1-to-400/
But since privacy is a major concern for them, they should just use our IP-to-country database and host an API themselves on top of it: https://ipinfo.io/lite
We are happy to support and be part of any software that want to use our data.
I was able to confirm that NetGuard actually uses the IPinfo API. See https://github.com/M66B/NetGuard/blob/master/FAQ.md#:~:text=... and https://github.com/M66B/NetGuard/blob/31652781967a70efaee2eb....
I agree that it would be a more privacy-friendly solution for them to host their own API, but that got me thinking, wouldn't it be possible to just let users download the IPinfo data and use it locally? Does IPinfo offer database downloads? That's also how the Server-Status Firefox extension (https://github.com/tdulcet/Server-Status) works (but it doesn't use IPinfo). Also asking for potential personal use: How does the quality of IPinfo data compare to MaxMind, DB-IP, etc?
Apologies for the late response. It's awesome to see they're using our data. I did not know that.
> wouldn't it be possible to just let users download the IPinfo data and use it locally? Does IPinfo offer database downloads?
Of course, you can download our free IP database right now: IPinfo Lite
https://ipinfo.io/lite
> Also asking for potential personal use: How does the quality of IPinfo data compare to MaxMind, DB-IP, etc?
We are miles ahead of everyone in terms of accuracy. Currently, we have 1,100+ PoPs across the world running active measurements. While traditional IP geolocation services are no much more than ASN/ISP reported data aggregation and parsing services. Our priority above all is accuracy and at this moment we are likely the industry leader for that.
If you have the time, go through some of our posts in our community and you will be surprised how good our data is right now. I will share my recent favorite one:
https://community.ipinfo.io/t/the-north-korean-gamers-on-ste...
When viewing the "Show log" screen in Netguard, under the top right, three dot menu there are checkbox options for "Show names" and "Show organization". Netguard sends requests to ipinfo.io to get information about IP addresses. These requests to ipinfo.io do not show up in the Netguard log.
There is no cause for concern necessarily. These are design choices, nothing more.
Users have no idea what happens to the data that leaves their computers. To quote from another story currently on the HN front page: "It's incredibly easy to give information away. But once that data is out there, it's nearly impossible to take back." https://news.ycombinator.com/item?id=44689059
Promises made by developers are reassuring to some, but rarely if ever legally enforceable in the event something goes wrong, and the harm already caused may be beyond redress. As a proactive measure users can, among other things, seek to minimise the amount of data they send. For example, some users might want the _option_ to stop their phones from constantly trying to ping or connect to remote servers _without any explicit user intent to do so_. Maybe they do not want their phone to act like a beacon to someone else's remote server.
The point of the comment is that sometimes there are remote connections being made to servers chosen by developers that are assumed to be OK with all users, e.g., connections to Graphene servers, IPinfo servers, or myriad other examples. Meanwhile there is no option for the user to disable this behaviour. There may be some users who prefer _zero_ remote connections except the ones they themselves choose to initiate or enable. The possibility of such users often seems to be overlooked or deliberately ignored.
Like Firefox constantly sending HTTP requests to remote servers to check for "connectivity". Even when the user is not trying to connect to any server. The requests are sent in the clear. This is not optional behaviour.
> Except the default browser is Chromium with some changes
Chromium has vastly superior security compared to Firefox. https://madaidans-insecurities.github.io/firefox-chromium.ht...
> It tries to copy Google paternalism > > It swaps a Google mothership for a Graphene mothership
Nonsense claims. All network connections made by the OS are well documented on the official website: https://grapheneos.org/faq#default-connections
There are only a few services GrapheneOS devices connect to:
- a time server (securely, over HTTPS, not insecure NTP)
- the OS update server (obvious; it's just plain HTTP requests, no user identifiers other than the IP address, which can easily be masked by using Tor or a VPN)
- the GrapheneOS App repository, which provides updates for preinstalled apps like Auditor, as well as the Vanadium browser and WebView (it's critical to get security patches for your browser in a timely manner)
- network connectivity checks (required to sign in to public wifis that use captive portals; can be entirely disabled in the settings)
- SUPL and PSDS through GrapheneOS proxies for A-GNSS because there is no network location service enabled by default
> Can connections to Graphene servers be blocked, i.e., are these connections optional or mandatory
You can block all the connections. You don't even need to, since they can all be disabled in the settings. If you disable the System Updater app, you're gonna have to adb sideload your system updates https://grapheneos.org/usage#updates-sideloading.
> If the concern is apps that only require internet connection for ads, Netguard solves that problem without root
You don't need Netguard, GrapheneOS has a built in network permission toggle, which offers even better protection than a firewall, since it completely blocks access to the underlying network socket (https://grapheneos.org/features#network-permission-toggle)
> The user-hostile design of Android is that apps keep running in the background after they are "closed"
You can deny apps running in the background, even on stock Android. This isn't unique to Android btw, I'm sure you've come across the system tray in Windows before. Those are all apps running in the background. Android basically has the same thing, it's in the notification center, and you can also stop background apps from there.
> 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 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.
I've heard good things about RethinkDNS but I've been waiting for integration with Tailscale[0], which doesn't sound entirely trivial[1]. :'-(
[0]: https://github.com/celzero/rethink-app/issues/1047
[1]: https://github.com/tailscale/tailscale/issues/12280
I put a Private DNS ('controld' for that matter) and never looked back. No more private VPNs with Blokada, no more block list updates. You choose if you want ad, tracker or adult blocking, without hassle, for free.
> 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.
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.
Are you referring to something like Karma on fdroid?
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.
I have been using Rethink, I think it is great.
Root, while more efficient, isn't strictly necessary. AdAway (FOSS, F-Droid) can run without root using the stock Android VPN backend.
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.
https://grapheneos.org/faq#baseband-isolation
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.
https://osservatorionessuno.org/blog/2025/03/a-deep-dive-int...
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.
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.
I agree with you. I think FSF RYF is a pointless certification since firmware isn't going away anytime soon. I'm not a fan of their "it's part of the wiring if you can't upgrade it" compromise either since it doesn't achieve their goals and makes the situation even worse.
It would be nice if the firmware itself was free software so that it could be shipped alongside the Linux kernel, maintained indefinitely and we could customize it however we want. The hardware is supposed to do what we want it to do, not what the manufacturer lets us do.
I don't like the fact every single device out there has entirely separate computers inside them running unknown proprietary software. It feels like our operating systems aren't operating the system anymore, it's like they're just some user app sandboxed away from the real system. This presentation explains what I mean:
https://youtu.be/36myc8wQhLo
It's an imperfect reality. Security by isolation of devices via IOMMU addresses real concerns such as devices being able to access RAM via DMA. It's great that GrapheneOS is doing this.
Was there ever? And is the situation improving or worsening?
I am alright with things that allow for improvement, at least in theory
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.
Not sure what the situation is with Librem, Pine and Joola/SailfishOS, maybe those qualify?
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.
AOSP is coming to an end...
https://old.reddit.com/r/StallmanWasRight/comments/1l8rhon/a...
https://news.ycombinator.com/item?id=44254540
No, someone took an out-of-context screenshot of information conveyed by the GrapheneOS account and misrepresented it. We were describing what a source we described as unreliable told us based on what they said was a leak from Google. You can see we didn't say what was claimed but rather were describing information from a source ("they said", "according to the source"). It was fully clear in the context the screenshot was taken that this was someone's speculation to us based on a leak and that we didn't consider it reliable information. Part of it turned out to be correct so we shared the information to discuss it.
Following this, we posted multiple threads correcting inaccurate claims about what we had said about this and made it clear GrapheneOS was continuing. GrapheneOS was fully ported to Android 16 before the end of June, which took longer than usual due to the changes but was still completed.
Open source drivers is a big step forward we must not discount, creating a separation between hardware trust and OS trust.
That said, to your point, both are misrepresented as fully open frequently which is just not true, and obscures efforts by teams that are working on fully open hardware solutions the hard way.
> creating a separation between hardware trust and OS trust
Typical Android devices have fully open source kernel drivers. There are usually dozens of closed source libraries in userspace such as the well known Mali GPU driver library. Closed source libraries can still be reviewed. Open source doesn't make something secure and trustworthy. It also isn't a hard requirement to review a library. Auditing a low-level C library doesn't imply finding all the vulnerabilities, particularly something hidden. Widely used open source code still has many vulnerabilities lasting for long periods of time after many people have reviewed it. It does not solve security or trust.
> That said, to your point, both are misrepresented as fully open frequently which is just not true, and obscures efforts by teams that are working on fully open hardware solutions the hard way.
A closed source SoC with open source hardware built around it and other closed source components including radios is not a fully open source computer either.
Purism uses U-Boot on the Librem5 and modified coreboot (in other places) I believe.
https://docs.u-boot.org/en/latest/board/purism/librem5.html
This doesn't mean it's open hardware or that it has open firmware. It has a closed source SoC and many other closed source components. Those components are closed source hardware with closed source firmware.
Snapdragon uses a fork of the open source EDK2 as their bootloader prior to the OS and publishes the source code. It doesn't mean Snapdragon is open source.
Most of the firmware has nothing to do with the boot chain leading up to the OS on the SoC.
That’s standard at a low level I believe. There are almost no open choices way down there, especially with modems.
Looks like they are doing what a small company is able to do.
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.
Replicant was the last time we had fully open Android devices. We have regressed.
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 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.
They did not replace firmware with open alternatives. Not updating firmware is not replacing it.
> 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.
They steer people to devices with severe unpatched firmware vulnerabilities and an enormous number of severe unpatched software vulnerabilities in the case of Replicant. This is covered up and people are misled about it. These projects claiming to be focused on avoiding backdoors are in fact deliberately backdoored through not patching known vulnerabilities for ideological reasons.
> 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.
You still trust the developers of open source software and firmware. Open source doesn't result in all vulnerabilities being found, including intentional ones. It's not even close to providing it.
> This is why I reject platforms that require closed firmware in the first place to the fullest extent I can.
The platforms you're describing as having fully open firmware still have closed source firmware.
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 hardware, 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, with huge form factor and no power management. I still own one anyway because we have to start somewhere.
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.
> 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.
MNT Reform has a regular closed source ARM SoC as the main component along with a bunch of other closed source components. The chassis, board and boot chain being open doesn't make a device mostly open hardware. Anything simply using an ARM or x86_64 SoC at the core is not truly mostly open. It's a closed source system (the SoC) with open source components between it and other closed source components like radios, a display controller, SSD, etc. The same applies to other ARM and x86_64 laptops. They're built around closed source components even if the board many components go in and the boot chain is open source.
Having an open source boot chain and not requiring loading proprietary firmware from there or from the OS doesn't mean the device has open firmware. It's conflating not needing to load firmware with the firmware not existing or being open, which isn't the case.
> The Precursor is the only pocket computer platform that is maximally open hardware, 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.
This is far closer to being how you're describing other platforms. However, it does have closed source components including the FPGA and Wi-Fi. It's as close as it gets to being open hardware and that has a huge cost. Platforms simply using a closed source ARM SoC and many other closed source components are not anywhere close to being open. This is what it takes to get close, and it's not fully there.
> 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, with huge form factor and no power management. I still own one anyway because we have to start somewhere.
It's the motherboard that's open source. The IBM CPUs used with it are not open hardware.
> 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.
Laptops with a nearly completely closed source SoC / CPU are not a fully open platform, especially when it's an SoC providing most of the functionality. Talos II has a lot of functionality on their open motherboard vs. an ARM SoC with most of it on the SoC, but either way the CPU being closed source is still the most core component being closed source.
Note I described MNT reform as -mostly- open and the Precursor as -maximally- open (as in the the maximum extent currently possible to mass produce).
If Bunnis ASIC efforts succeed, then we have auditable reasonably fast chips in the next few years and a truly 100% open device. Tropic Square is another to keep an eye on.
Fully aware of everything in your descriptions here, but you always repeat this stuff as though I am not. Probably useful for others though.
Where we always seem to disagree is you usually try to dismiss mostly open solutions as no better than mostly closed as though the effort to pursue transparency is pointless. I feel every single component with open firmware and open hardware is a huge win, making accountability and community improvement possible. Likewise every blob is an eyesore that should be reverse engineered and replaced... or switch to more transparent alternatives when they exist.
Sure, auditing never catches all bugs, but it catches a -lot- of them. There are many severe security flaws I would never have had a chance in hell of having the time to find in closed binaries, let alone fixing them.
Sure underhanded C and all sorts of sneaky bugs can exist, but an open C solution could be replaced with an open Rust solution structured for east auditing or another language that makes it harder to do many common types of sneaky in.
If a vendor will not let me look at their code, I am extra suspicious of glaring backdoors or bugdoors until proven otherwise given countless examples in the wild.
I have always agreed open source alone does not mean code can be trusted. Most open source code is shit and should -not- be trusted (I review it for a living) but I am absolutely certain open source is an prerequisite to a community maintainable trustworthy solution existing where we get both freedom and security.
> Note I described MNT reform as -mostly- open
It's near completely closed source hardware. The SoC providing nearly the whole core system is fully closed source. An open source boot chain after the closed source early boot doesn't change this. Other components are closed source too. It's closed source with open source bits in between. Compared to the complexity of the SoC, radios, etc. the open source parts are insignificant. Open source between closed source components with most of the complexity it not mostly open source. It's simply not true.
> and the Precursor as -maximally- open
It's possible to use an open source RISC-V SoC instead of programming a CPU with a closed source FPGA. They don't use a closed source FPGA to be maximally open but rather to be closer to being able to inspect it.
> Fully aware of everything in your descriptions here, but you always repeat this stuff as though I am not. Probably useful for others though.
I don't think you're unaware of it. You must be aware the MNT Reform has a fully closed source ARM SoC with most of the core system's complexity but you still call it mostly open source.
> Where we always seem to disagree is you usually try to dismiss mostly open solutions as no better than mostly closed as though the effort to pursue transparency is pointless. I feel every single component with open firmware and open hardware is a huge win, making accountability and community improvement possible. Likewise every blob is an eyesore that should be reverse engineered and replaced... or switch to more transparent alternatives when they exist.
They are not mostly open solutions. It's false marketing. Open source does not have the properties you claim it does of heavily avoiding trust in the developers or providing much better security.
> Sure underhanded C and all sorts of sneaky bugs can exist, but an open C solution could be replaced with an open Rust solution structured for east auditing or another language that makes it harder to do many common types of sneaky in.
Memory corruption isn't required for serious subtle vulnerabilities and even safe Rust has plenty or room for memory corruption. Rust does not making auditing easy. It makes it easier than C, which is a low bar. Auditing C for deliberate vulnerabilities can easily be harder than auditing assembly code without anything that looks obfuscated.
> If a vendor will not let me look at their code, I am extra suspicious of glaring backdoors or bugdoors until proven otherwise given countless examples in the wild. > > I have always agreed open source alone does not mean code can be trusted. Most open source code is shit and should -not- be trusted (I review it for a living) but I am absolutely certain open source is an prerequisite to a community maintainable trustworthy solution existing where we get both freedom and security.
There are many glaring vulnerabilities in the most widely inspected open source projects including the Linux kernel. Many have persisted for not only years but decades. Open source does not inherently result in all these vulnerabilities being found and fixed, whether they were intentional or not. Open source can help with it but it provides no guarantee of better security.
Linux kernel is a typical collaborative open source project where performance, scalability and features trample over security. It being such an expansive and collaborative project means there's massive attack surface for intentional vulnerabilities and it doesn't have serious protections against it. Lack of prioritizing correctness and security for nearly all of it is pretty much equivalent to intentional vulnerabilities. Deciding not to deploy very useful features for finding / fixing vulnerabilities due to minor work it creates is typical, such as not marking intended overflows to have automatic overflow checks as an option. There's massive pushback against very basic things. The effort to introduce Rust for drivers has gone horribly despite lots of resources and it's face far greater resistance in the core kernel. Meanwhile, iOS has a kernel increasingly focused on security where they overhaul the whole thing for it. This is an example where one company controlling a project without collaborative is a massive win for security. There are projects like SQLite which don't take on the collaborative and open development aspects of open source. AOSP is similar to an extent, but heavily uses collaborative open source projects like Linux as core parts of it which largely don't have the same significant focus on security it grew over time. AOSP is about as security focused as iOS itself, but open source projects they use including Linux certainly aren't.
You keep confusing me saying open source is a -prerequisite- for maintainable freedom and security, and does nothing for security itself.
You only ever read the parts of what I say and continue to argue as though I think open source code is inherently secure, and continually ignore every time I AGREE with you that most open source code is shit.
Please listen when people are largely agreeing with you instead of hitting back with walls of text as though they are not.
MNT reform is mostly open in terms of everything but the CPU. That is a -great- start as it means fewer parties you have to trust. Also they support two different CPU vendors as well as an FPGA option soon. The CPU is a swappable component in an otherwise open platform. How can you dismiss that level of flexibility and user power as anything but substantial progress over the status quo? Please give people working hard for more freedom respecting hardware their due credit. Minimizing such very hard work will not win you allies.
Also yes, the Linux kernel is a security shit show to be sure, as well as mot desktop Linux distros, but -because- it is open I can heavily patch it and customize it to reduce attack surface.
Also because it is open projects like Asterinas can reference it to make an ABI compatible modern replacement is Rust which is making rapid progress!
Transparency is step 1 to any major progress in freedom and security and that is why I am a broken record demanding more of it from all projects widely used in high risk scenarios.
As opposed to using what, hand gestures? There is simply no production ready hardware with non-proprietary software at all.
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.
> As opposed to using what, hand gestures
As opposed to "being free in all senses of the word", which is what the comment was talking about.
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
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.
This is also the case with mainline linux though. Good luck using Nvidia graphics with only FOSS components.
Even more FOSS friendly graphics vendors like AMD and Intel rely on binary firmware.
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.
Indeed, mainline linux distros aren't free software either
I have run nvidia cards without proprietary drivers for years. Nouveau.
With the right hardware choices running blob-free linux is pretty straightforward.
> Nouveau.
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.
An Nvidia GPU is never going to run at maximum clock speed etc on open drivers right now, but the point is if you prioritize security/privacy/freedom you have choices.
If you are not running games (which you should not on a system you need to be able to trust) maximum clock speed from a modern GPU is not needed for most workstation applications.
I generally choose AMD GPUs for the best experience with open drivers these days on systems I need high GPU performance from.
> You need proprietary microcode blobs to fix those security vulnerabilities in your CPU.
Really? Which blobs do I need on RISC-V FPGA enclaves or my PPC64le Talos II workstation which has a fully open hardware motherboard and open CPU architecture?
I make different tradeoffs on different hardware to be sure depending on the threat model of the task I am working on. x86_64 is a bit of a shit show, but you still only have to trust your CPU vendor even there, as it is possible to have FOSS firmware/software for everything else.
> PPC64le Talos II workstation which has a fully open hardware motherboard and open CPU architecture?
The ISA is open source, not the whole CPU architecture and design. There are older open core designs from IBM but that's a different thing from the more modern and powerful Power9 and Power10 CPUs.
> you still only have to trust your CPU vendor even there, as it is possible to have FOSS firmware/software for everything else
A device with assorted closed source components including as part of the motherboard itself is hardly open beyond the CPU. Open source also doesn't mean you aren't trusting those vendors. With a fully open hardware design CPU, you're still trusting that it matches the open source design and you're trusting the open source design. The manufacturing process is also generally going to be proprietary.
> generally choose AMD GPUs for the best experience with open drivers these days on systems I need high GPU performance from.
Do you count binary firmware as 'open' or not? If not, AMD is not 'open' either. If you do, Nvidia now also has open kernel drivers. Mesa developers are exploring ways to get the new Mesa Nvidia Vulkan driver (NVK) to run on top of the open Nvidia kernel driver, which should eventually make Nvidia drivers as open as AMD.
The binary firmware on an external module over a PCI bus should not have the ability to manipulate my current operating system and exfiltrate data without being noticed, but it is a non zero chance which is why on all my x86_64 workstations I run QubesOS so most hardware components are well isolated from each other with hypervisors, in addition to only open source code in my operating system and kernel layers, which is best effort today on such systems.
I generally only run gaming graphics cards on dedicated gaming machines, not on workstations I need to be able to trust. You can't use accelerated graphics in qubes anyway, specifically because graphics cards are hard to trust.
My requirements from a workstation are:
1. MUST have 100% open source code loaded in system memory
2. SHOULD have open source software in the boot trust path (coreboot/tpm2 secure boot, etc)
3. SHOULD have open hardware to the furthest extent possible that meets my use case
4. SHOULD be fully auditable and tamper evident using at-home tools and methods (like the Precursor)
> maximum clock speed from a modern GPU is not needed for most workstation applications
Well at that point buying a GPU is definitely not worth your money. You're better off using a CPU's integrated graphics unit.
> I generally choose AMD GPUs for the best experience with open drivers these days on systems I need high GPU performance from.
Yeah I agree on that, I also purchase AMD cards exclusively now.
> Which blobs do I need on RISC-V FPGA enclaves or my PPC64le Talos II workstation
I assumed we were only talking about x86. But I also believe that POWER9 CPUs don't have SSE, prove me wrong. I guess you're running Linux? I'd be very interested in looking at the output of lscpu from one of these machines.
> x86_64 is a bit of a shit show
I fully agree there
> Well at that point buying a GPU is definitely not worth your money. You're better off using a CPU's integrated graphics unit.
Yeah I only use dead simple workstation cards or integrated graphics on my workstations, and AMD GPUs on my gaming systems which I don't trust at all (but still prefer to support companies that use open drivers)
> But I also believe that POWER9 CPUs don't have SSE, prove me wrong.
POWER9 has its own SIMD system (AltiVec/VMX/VSX) instead of SSE which is entirely its own thing. I have no idea of the performance tradeoffs here though for various use cases, as freedom is biggest factor for me.
> I'd be very interested in looking at the output of lscpu from one of these machines.
Here is an lscpu from an 8 core Blackbird though it will probably render poorly on HN.
Architecture: ppc64le Byte Order: Little Endian CPU(s): 32 On-line CPU(s) list: 0-31 Model name: POWER9, altivec supported Model: 2.3 (pvr 004e 1203) Thread(s) per core: 4 Core(s) per socket: 8 Socket(s): 1 Frequency boost: enabled CPU(s) scaling MHz: 58% CPU max MHz: 3800.0000 CPU min MHz: 2166.0000 Caches (sum of all): L1d: 256 KiB (8 instances) L1i: 256 KiB (8 instances) L2: 4 MiB (8 instances) L3: 80 MiB (8 instances) NUMA: NUMA node(s): 1 NUMA node0 CPU(s): 0-31 Vulnerabilities: Gather data sampling: Not affected Itlb multihit: Not affected L1tf: Mitigation; RFI Flush, L1D private per thread Mds: Not affected Meltdown: Mitigation; RFI Flush, L1D private per thread Mmio stale data: Not affected Reg file data sampling: Not affected Retbleed: Not affected Spec rstack overflow: Not affected Spec store bypass: Mitigation; Kernel entry/exit barrier (eieio) Spectre v1: Mitigation; __user pointer sanitization, ori31 speculation b arrier enabled Spectre v2: Mitigation; Software count cache flush (hardware accelerated ), Software link stack flush Srbds: Not affected Tsx async abort: Not affected
I think they don’t even have basic location mocking. They have disable or enable. But some apps won’t work.
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.
I believe this is in the works: https://bsky.app/profile/grapheneos.org/post/3lqbhoqwrjs2y
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 basically only useful for debugging.
Not by default, but there are several apps on F-Droid that do this
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.
Can you give me one that works on a stock Android? I used to use one but it no longer works on newer Androids.
Where do you get the apps from? Google's App Store?
Obtanium[1], F-Droid[2], Aurora Store[3] and FFUpdater[4] are some options. Signal self updates from the APK download[6].
I recommend putting proprietary Play Store apps grabbed with Aurora Store in the work profile with Shelter[5].
[1] https://obtainium.imranr.dev/
[2] https://f-droid.org/
[3] https://f-droid.org/packages/com.aurora.store/
[4] https://f-droid.org/packages/de.marmaro.krt.ffupdater/
[5] https://f-droid.org/packages/net.typeblog.shelter/
[6] https://signal.org/android/apk/
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.
https://discuss.grapheneos.org/d/20212-f-droid-security-in-s... https://discuss.grapheneos.org/d/18731-f-droid-vulnerability...
They also say, if you use F-Droid, at least use F-Droid Basic:
> Dont use the main F-Droid client. Android is pretty strict about SDK versions and as F-Droid targets legacy devices, it is very outdated.
https://discuss.grapheneos.org/d/11439-f-droid-vsor-droid-if...
> 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).
https://discuss.grapheneos.org/d/16589-obtainium-f-droid-bas...
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.
If the signatures are the same, what difference does it make which binary is distributed?
What is the same is the checksum of the result binary.
Work profiles are inferior to separate user profiles, which are built-in to GrapheneOS.
Also "private space" is now available with Android 15 and can provide the same separation within a single user profile.
> 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.
Also check out Neo Store: ''An F-Droid client with modern UI and an arsenal of extra features.''
https://github.com/NeoApplications/Neo-Store
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).
I put them in the private space. Is there an advantage on putting them in the work profile?
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.
Aurora Store on F-Droid is a FOSS frontend for the Google Play Store that is a seamless drop-in. Requires no Play Services, nor an account.
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.
But than the apps you download (your banking app) require play services right?
So then what's the point of having a Play Store without Google Play services?
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.
Not all apps on play store require play services.
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.
tl;dr: 10/10, fabulous experience.
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".
F-Droid app store. https://f-droid.org
do you need to access your mobile for bank accounts ? does that work ?
Someone's keeping a list of banking apps known to currently work with GrapheneOS: https://privsec.dev/posts/android/banking-applications-compa...
Check if yours is on the list.
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.
No, the reason is legal. Everything, and I mean everything else is secondary. They can tell in court that they did everything what they could. Of course:
- it’s a lie
- not even a white lie, they know perfectly well, that they can do way more
- most of the security “features” are completely useless
- they also know this
However, it’s very difficult to prove these, and laymen don’t and won’t understand the details.
And if any law ever goes after them it'll be years before any court charges them with anything.
By that time the amount of money that will have been made can justify and exceed whatever fine they might expect to get in court.
Is there a link that explains this for bank apps specifically?
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)?
Because in infinite banking sector's wisdom, logging into the website requires a confirmation with the mobile app.
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.
Are there banks without such requirement these days?
Schwab works with totp as 2fa.
Last time I looked they required some Symantec BS to intermediate. Has that ended?
I don't know if it has ended but you could reverse engineer the Symantec BS and convert it to regular totp. You likely need root to extract the internal store from the symantec app.
All banks I know that do this have an alternative 2FA you can use instead tho.
Ask for an alternative authentication mechanism because you "do not own a smartphone".
I've changed banks for less.
I'm concerned about losing phones too, so I don't bank on any phone.
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?
In Sweden all the banking apps I've tried works, including BankID.
Can you use mobilepay? (Or is that not a thing in Sweden?)
I've never heard of it.
In Sweden we typically use Swish, which again works great.
"Tap to pay" things are problematic though but it's not something I personally use (even before I migrated away from stock Android).
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
I have a rooted Graphene on a Pixel 9, and the only bank which isn't working is Revolut.
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.
As a single datapoint, revolut does not work unfortunately, so I moved back to the default pixel OS.
I can’t recall the switch, I believe it’s mem exploit protection. When disabled it typically fixes banking apps. You tried that?
GrapheneOS published a workaround for that in an update in January. https://grapheneos.org/releases#2025012600
https://grapheneos.social/@GrapheneOS/114772578787013282
Revolut works perfectly for me.
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?
Revolut does work for me. They added support for GrapheneOS long time ago
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)
Thanks, then I might have another go at graphene! That was the only reason I went back to vanilla "pixel OS".
Did you have to turn off mem exploitation? And have google play services? Revolut did not work for me recently.
https://grapheneos.org/donate
If you want it to stay free
have you used something like lineageOS before?
I agree. I love using Graphene OS. Came for the security, stayed for the lack of bullshit.
GrapheneOS? On a Pixel? You must be one of those criminals /s
Arrest this individual
Happy long term user, great project. Here is a list of Open Source Apps, I use to replace Google stuff:
I wish I had this list from the start... Hope it helps someone :-)Worth mentioning that Fossify also has an amazing Contacts and Calendar app (using both right now on Android 15).
https://www.fossify.org/apps/
Fossify is a FOSS project with a handful of volunteers and they do take donations:
https://www.fossify.org/donate/
> 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)
[1] https://f-droid.org/en/packages/app.comaps.fdroid/
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)
I don't think the fork is very different right now, and I doubt inputting addresses works differently.
You might want to try:
- writing the city name at the beginning
- putting the street number at the end
Note that OSM might not have the street number. If it doesn't, searching for it will fail for sure.
You should probably file an issue: https://codeberg.org/comaps/comaps/issues
Can also recommend:
Aegis: TOTP 2FA code manager
SuperCards: stores shop loyalty card barcodes
KeePassDX: password manager
ReadEra: eBook reader
Magic Earth: another maps app
Vivaldi: power-user's browser
JuiceSSH: SSH client
Termux: like running a Linux term
AntennaPod: podcasts
I do not use Aegis anymore, I use KeePassDX instead. It works for TOTP just fine.
JuiceSSH is still under development?
Some people don't like to keep passwords and TOTP in the same place.
Why? Both are on my phone, although KeePassDX database is exported and backed up. I do not use the desktop application, but I might.
If it is compromised, both your passwords and TOTP are compromised, which kind of negates the point of multiple factor authentication. If they are in separate apps, hopefully both won't be compromised, at least not at the same time.
If my phone is compromised, probably neither of them are compromised, or both are. I do not see how a separate app helps. I see where you are coming from, but I think using KeepassDX for password and TOTP should work. Keep in mind you can have multiple databases, you can store the TOTP only in one of the databases.
>Magic Earth: another maps app
>Vivaldi: power-user's browser
Propietary. Get Fennec with FDroid with Ublock Origin and some addons.
Exactly. My favourite extension is Consent-O-Matic to auto accept annoying (and meaningless) pop ups.
CoMaps: another maps app
StreetComplete: help update CoMaps and OpenStreetMap
Catima: for loyalty cards
I'm surprised no one mentioned NewPipe, the best YouTube App. A few other apps I use Feeder - RSS App Fedilab - For Mastodon
I prefer Tubular which is a NewPipe fork with not only an ad blocker, but also with SponsorBlock and ReturnYouTubeDislike.
I also use PipePipe.
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?
> 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.
Awesome! Thanks for sharing this.
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.
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.
NextCloud - sync photos, calendar, notes and contacts to your own server.
Does the NextCloud app now sync contacts and calendar? Last time I tried, years ago, it did not. I use DAVx5 to sync my NextCloud contacts and calendar, via CardDav and CalDav.
No, not directly. It has server support, but I also use DAVx5 on the client.
for someone who doesn't want to replace Google services, does it still make sense to move to Graphene?
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.
According to Terence Eden, Curve Pay allows NFC payments, at least in the UK
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!
[0]: https://news.ycombinator.com/item?id=44259921
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.
> We're working with a major Android OEM to change that though, hopefully for 2026 or at least 2027.
Is there any chance that you fabulous guys could lobby for a smaller <5 inch phone with that OEM? (reference https://news.ycombinator.com/item?id=44586723)
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 Sony Xperia XZ1 Compact was the perfect size phone and I hate the world for not having successors of the same size.
It is so annoying that all current smartphones are so large and heavy. The XZ1 Compact could be even smaller now considering the large case frame around the display. That would be amazing.
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.
I doubt that GOS will be able to move the needle on such a decision. But I'm also someone who'd love to have a small and more light-weight smartphone again. A smaller display of maximum 5.1 inches or so would also be in line with a sentiment of using the smartphone for its core purpose over attempting to turn it into a small PC for playing games and what not. I believe this correlates with a more secure phone.
Do you guys all have that small pockets? I have a 6.7" Smartphone and never had an issue with its size
Oh it's not pockets. I just have tiny raccoon paws for hands.
I like being able to reach across the keyboard one-handed (to shift, etc) and I can't do that on modern, larger phones.
It's not even small hands. I have huge hands and still can just barely reach the top of the screen when using my phone singlehandedly.
In some keyboards (like Florisboard) there are options to either left-align or right-align the keyboard, which helps you to do that, even on a big smartphone
I like to wear light weight and loose-fitting linen pants. My iPhone 13 feels like a little brick in them.
Fair
Well, I hope both of our preferences will be offered
Seconded! Need a smaller phone! and video out means i can make screen biggger if i want!
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 ?
Thanks again!
> Because you said discussion are being done with an OEM, will GraphaneOS switch from pixels to a different device?
Pixels will be supported until end-of-life. Future Pixels will be supported if they continue meeting our requirements.
> 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 ?
We expect 10th gen Pixels to meet our requirements and we should be able to add support for them. It's not going to happen in 12 to 48 hours from the official launch of the devices as we did for around the Pixel 6a and later. It will be more work. We've automated most of the device support for existing Pixels now and have removed nearly all of the Android 15 QPR2 device trees rather than manually updating them. We're continuing to automate more and will use that approach for supporting new Pixels.
The devices with an OEM partner are further in the future than the Pixel 10. We need Qualcomm's new SoC with hardware memory tagging support to launch because a flagship Snapdragon is the best fit other than the current lack of hardware memory tagging. Some things need to be addressed by the OEM including licensing extra things like Qualcomm and filling in some missing features. There needs to be a clear, workable plan for updates including Linux kernel LTS branches.
Makes sense, thanks for the reply!
I've never owned a pixel, but I'm planning on getting the pixel 10 so I can use the new android 16 Linux terminal with graphical support. I hope the pixel 10 will still fit your requirements and it won't be a hurdle to port GOS without the device tree. I see no other OEM supporting the level of virtualization with kvm and vergil Google is bringing to the pixels. Good luck!
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.
Good to know. Thank you and good luck!
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... :(
Agreed, pixel oled (and iphone oled) make my eyes blurry and achy and ia ssume its the pwm. ips laptop, other phones never have this effect
for me a non-OLED screen would be a non starter. I love reading text (white text with black background) and watching HDR videos on OLED screens
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!
The comment above was describing in great detail how this is not the case and after some initial effort should prove no difference at all.
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..
Is it now possible to build a custom release of graphene for any of my non-Pixel devices or will that, again, bring graphene ninjas to my abode?
I am so excited about the thought of a GrapheneOS native phone!
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...
> If they are selling off their device business
Android and Chrome are potentially going to be split from Google:
https://www.nytimes.com/2024/11/20/technology/google-search-... (https://archive.ph/egRL4)
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.
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]).
[0]: https://www.androidauthority.com/google-not-killing-aosp-356...
[1]: https://www.bloomberg.com/news/articles/2024-11-18/doj-will-...
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.
They have this which wipes your device, but you can get killed under duress. https://discuss.grapheneos.org/d/14722-using-duress-password...
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.
[1] https://9to5google.com/2023/11/20/lineageos-number-of-device...
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.
Google has no access to anything you do on a Pixel with GrapheneOS installed just because it's their hardware.
Explain this please. With enough detail for the HN gurus.
https://grapheneos.org/features#sandboxed-google-play
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.
> Tbh I’d say 99% of the criminals won’t know about this.
It's not about criminals. It's about the police, government spy agencies, and other knowledgeable threat actors.
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.
Yes, 100% this. Plausible deniability for everyone does not hurt everyone, it rather protects everyone, even if you don't use it.
I've seen this be requested for years from various mod users. Is it too difficult to implement or something?
They say a hidden profile is not secure enough so not worth implementing.
I rather have this hidden profile that would stop 99% of criminals than what they have now.
I think their approach to this project is to deliver real security at the cost of features.
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.
We use Flarum as our forum software for https://discuss.grapheneos.org/. Flarum supports viewing all of the content without JavaScript via an HTML fallback mode using pagination. Flarum simply informs people they'll have a better experience with JavaScript enabled.
Join usenet: https://www.eternal-september.org
Subscribe to comp.mobile.android. Sadly there's no libre client yet, but Mozilla might release a Thunderbird version with NNTP support.
You can read it just fine with Javascript disabled, though.
It's Discourse.
We use Flarum for our forum, but Discourse similarly only allows one to view forum posts without JavaScript enabled.
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.
[0] https://lineageos.org/
[1] https://grapheneos.org/faq#supported-devices
>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.
> We use Apple's location service, not beaconDB.
I stand corrected. Do you have plans to switch to BeaconDB when the coverage in the USA improves?
We're building our own fully offline implementation. Our existing implementation is semi-offline and does the position estimation locally based on downloading data kept in an in-memory cache for a limited time. We're close to what's needed for offline support already in that sense. We need to finish scraping the data and putting together a system for distributing and using it.
In newer Android versions, network location with microg requires an additional patch to work. Else you only get GPS.
See note at the bottom here: https://github.com/microg/GmsCore/wiki/Installation
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
GrapheneOS community manager here. Google's devices are currently the only ones that meet our requirements (https://grapheneos.org/faq#future-devices).
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.
We really appreciate the kind words!
I can only attest to that. Been using it for 3 years on a Pixel 6a. The only thing I'd wish for, is a scrolling PDF viewer.
In any case, thank you for all the work so far!
Librera Reader has a scroll mode : https://f-droid.org/en/packages/com.foobnix.pro.pdf.reader/
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.
I got curious and found this: https://discuss.grapheneos.org/d/7208-8y-security-updates-on...
At the risk of doing their work for them, that seems like a near ideal partnership opportunity for graphene, so it’s extra sad to see.
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.
https://discuss.grapheneos.org/d/24134-devices-lacking-stand... is a better thread about this than the one you linked.
That looks like a real shame and granted not the fault of graphene.
Why would their OS patches effect your different OS? It would be hardware you're supporting, no?
I'm working my way down your requirements.
> Hardware memory tagging
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?
MTE is an Arm v9 feature subset of CHERI, https://news.ycombinator.com/item?id=30007474 | https://armor.ch/mte/hw
https://discuss.grapheneos.org/d/8439-mte-support-status-for...
> 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.
I really hope it's the Nothing Phone you're talking to.
About the OEM, are you working on having devices ship with GrapheneOS, or devices be GOS compatible (i.e. same as the Pixels)? If you're thinking of devices shipping with it, would this fix the issue of Play Integrity/SafetyNet failing? That's the main reason I am running the android on my phone, as my banks don't work with Play Integrity failing and I have to use the app for 3DS. The ability to run GOS without this issue would be huge.
>About the OEM, are you working on having devices ship with GrapheneOS, or devices be GOS compatible (i.e. same as the Pixels)?
As far as I'm aware as an outsider, the aim is a device that is compatible with GrapheneOS like the Pixels, yes.
>If you're thinking of devices shipping with it, would this fix the issue of Play Integrity/SafetyNet failing?
I think to pass this you need to be 'blessed by Google' which means being certified Android by their standards. GrapheneOS have mentioned that their CTS/CDD Android certification process holds back some of the privacy/security features (think things like new Sensors and Internet permissions etc.) implemented so they cannot can't target it.
This is great to hear. I hope the ORM has a budget model graphene can run on.
that is great but i hope it is not a small run with a 200+ price as happens with the various linux phones.
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.
4-5 versions of the same phone in the gigantic sea of possible devices
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 other devices don't meet the criteria
you got it wrong way around
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"
Nobody said it was stupid, but you wanting something doesn't make it a requirement for a project with different goals.
car analogy: I want my gazoline car to have hybrid engine. For free.
vendor: not possible
you: unfulfilled demand
me: the way I see it, you get a product for free if you fulfill certain conditions. If not, you buy these conditions.
no, correct analogy would be
vendor: "we present 100% electric car"
we: "that's cool, I always wanted to decrease petrol use. But... can you provide an option for some petrol use? It's called hybrid, iirc?"
vendor: "no, our requirements only support 100% electric car. Hybrid cars use petrol and we can't allow that"
we: "suuure, I get that. But the price of electricity here still hasn't come down, everyone already has personal petrol reserves, and your cars are only provided with batteries from congonese child labor mines. Can we pleeease have the half-way option so that I can use less petrol for e.g. small distance travel, but still using petrol for country-sized movement?"
vendor: "no, we only support 100% electric car. Everything smaller is outside our requirements"
Real economics would've provided competition to fullfill demand - but currently Graphene is the only well-known vendor, so complaints will keep coming
What a bad analogy, acting as if the extra security could only be an all-in.
There are hardware requirements.
there are smaller security options
I was going to type something, but upon a second read I see you say 'consumer' instead of 'customer'. Fair enough.
https://calyxos.org/ does a few other devices, seems aimed strait at true privacy
GrapheneOS community manager here.
I would recommend checking out https://eylenburg.github.io/android_comparison.htm for a third-party comparison of these projects. They're not really similar.
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.
> 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 table shows CalyxOS has substantial delays for important privacy and security patches. It currently doesn't provide the 2025-06-05 patch level. It's better than LineageOS and /e/OS in that regard but still reduces privacy and security through significantly delayed patches. CalyxOS also weakens parts of the privacy and security model through the privileged functionality that's added, which simply isn't covered by the comparison table.
> 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.
On Pixels, CalyxOS is missing current Android privacy/security patches. GrapheneOS doesn't support those other devices due to lack of a reasonable level of security. Each of those extra devices has significantly delayed privacy/security patches and lacks important hardware-based security features. Despite all the marketing about long term support, Fairphone 5 uses Linux 5.4 which is end-of-life in December 2025 with no plans on their part to move to a supported kernel branch afterwards. Earlier Fairphones are stuck on older end-of-life kernel branches. Those devices are missing basic updates and security protections. Those don't provide proper long term support, so if someone does have one it won't be long before it's time to buy another device.
> 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.
> The security provided by GrapheneOS is in order to be able to protect privacy.
But there is still no way to reset/spoof android device ids, and the apps can reliably identify the user after reinstalls.
Hardware identifiers aren't accessible to user installed apps. ANDROID_ID is a per-app-per-profile random ID. Apps don't need ANDROID_ID to identify that it's the same install due to immense fingerprint surface. If you installed the app in another profile, it would have a different ANDROID_ID, but it would still potentially be able to fingerprint it as the same device based on many things like settings. GrapheneOS does have planned features to improve these things but it's not nearly as simple as making ANDROID_ID per-app-install or making the MediaDRM ID more randomized than the current per-app random value (it was meant to be like ANDROID_ID but they make a mistake that's hard to fix without breaking compatibility so we need a toggle).
I understand, but think it won't be correct to make claims about strong privacy while fingerprinting remains possible and as easy as on stock devices.
I agree that GoS did a lot in order to improve privacy (scoping) and it provides unmatched security, but you shouldn't create false expectations.
Why must your team replyguy every single CalyxOS post?
Sounds like google is going hostile to the project, so if enough of us miss it i guess we will have to work on new hardware support
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.
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.
por que no los dos?
Because as mentioned, Fairphone has lackluster hardware security.
You can have the best alarm system in the word, if you leave the back door open and anyone can just walk in from the street.
Okay, but the danger of vendor lockout is very great because gOS only supports one brand of phone. The justification for limiting support to pixels is that it has trusted computing features, but these are made unnecessary by having a long password.
You could just have some disclaimer on the grapheneOS site that says something like "Works best with pixel phones" or have some long password requirement on non-pixel phones
> but these are made unnecessary by having a long password.
Yeah, that's completely how security works...
It is. The idea behind using a embedded trusted computing device in this fashion is that you can store a AFU encryption/decryption keys in the trusted computing device and lower-entropy password like a 4-digit pin or biometrics, with the trusted computing device preventing a brute force attack.
But this is unnecessary if your encryption password has enough entropy in the first place, because it cannot be brute forced. This is the security model of most linux distros that use full disk encryption with LUKS. And android already lets you do this, it is just less convenient.
I use grapheneOS with a high entropy BFU password and a low entropy biometric AFU fingerprint. My linux setup works in the same way. The BFU password is the only "real" password that secures you and encrypts your data. The AFU password is a just temporary screen lock that is vulnerable to side channel attacks because the decryption keys are still in memory.
This is one particular aspect of security.
If the hardware is not done properly, then the whole thing is broken. E.g. you are useless with your encryption keys if your modem sucks and leaks data, or if the CPU can trivially be made to run custom code (and you just entered your encryption key into a software that just looks like the prompt you were looking for)
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.
Ok, fair enough, if we are looking at software side of "repairs" (updates). However I'm talking about hardware side of things - with Fairphone I can remove and replace the battery by myself (or even carry a spare if I choose to), while e.g. in the newest Pixel, 9a, the battery is glued in place.
As for the requirements, I will take your word for it. And I do appreciate that you put the emphasis on security as it is often overlooked. I guess what I'm saying is that having control over my phone (as opposed to BigTech or apps having the control) is for me a much higher priority goal than just security by itself. Hardware reparability is (again, for me) a close second.
Anyway, I hope you find a good partner for the phones, and I'm curious to see what you come up with!
> while e.g. in the newest Pixel, 9a, the battery is glued in place.
Is this really that big of an issue? It's like a couple dollar fee every 4-5 years or so.
The maintenance burden would be wayyy higher and the satisfaction with the project would plummet.
It's a catch 22. Support other devices, the software won't work as well or reliably or maybe buggy - users get pissed off.
Spent the time to make it not buggy on other devices = now you're doing mor dev work than even Google.
The most fun feature of GrapheneOS is the ability to look at the logs of any app at any time from the App Info page.
wow I had no idea that feature was even there. Thanks for the heads up :)
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.
Hardware attestation and Google Play Integrity are two different things, and the former solves the monopolistic practices of the latter.
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.
That's immensely good news. It's good to know that there's still hope.
> We also expect Google's Play Integrity API to inevitably be ruled as anti-competitive, which it is.
I certainly hope so.
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.
yeah but lineageos with μg is quite good.
unfortunately it doesn't support google pay, which is a dealbreaker for me
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.
Phone-wallet case.
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.
According to the developers, beside the AOSP software itself, there seems to also be hardware requirements that only the Pixel satisfies.
https://grapheneos.org/faq#future-devices
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.
Our hardware requirements are listed at https://grapheneos.org/faq#future-devices. There are a small subset of other devices with at least nearly all of the security features we require. However, those devices either don't allow using another OS or cripple security for it. There's no other device providing the listed security features and allowing us to support it. Pixels are also the only devices properly keeping up with current Android OS and security updates. We need ongoing firmware and driver updates. There are other devices offering support for a similar time period, but not actually providing close to the same thing during that time period.
Most OEMs do the bare minimum for security. The security features they provide are the ones provided for them by AOSP, the SoC vendor, etc. They provide delayed and quite incomplete security patches.
Android downplays the fact that it has OS releases every month. There's a new monthly, quarterly or yearly release each month. The monthly Android Security Bulletin patches are a separate thing providing backports of a subset of the security patches (most High and Critical severity AOSP patches) to older initial yearly releases (the initial releases of Android 13, 14, 15 and 16). There are also a huge amount of SoC and other hardware-related security patches with a small subset included in the Android Security Bulletin. Most OEMs struggle to provide these backports and vendor patches on time for a reasonable time period. Non-Pixel OEMs eventually update to a new initial yearly release, usually quite late, then rely on the backports to it for a year or more. Full Android security patches mean shipping the latest stable releases, which have been through significant public testing beforehand for quarterly/yearly releases and are not actually bleeding edge. Quarterly releases are as large as yearly ones but awareness of them existing is low. Android 16 QPR1 currently in Beta has more user-facing changes than Android 16.
We're working with a major Android OEM towards some of their future devices meeting our requirements and providing official GrapheneOS support. It will be their regular devices but meeting our requirements currently only Pixels do. Hopefully available in 2026 or 2027. There's no reason other devices can't provide comparable or better security than Pixels, but it's not easy or cheap.
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 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):
https://grapheneos.org/articles/attestation-compatibility-gu...
Yes, I know the issue, but my question was more: is Revolut one of such banking apps?
Yes https://discuss.privacyguides.net/t/revolut-is-blocking-new-...
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.
Hey, thanks, I missed the news! Will try again!
OK, and then these HN users who report being able to pay via NFC with Revolut on Graphene OS are lying? Sorry, I am confused :|
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.
Impressive! Glad to be able to use Revolut again. Wondering, is this a change or their end or some workaround implemented by Graphene?
NFC payments work on GrapheneOS. Curve Pay works with GrapheneOS and is available in the UK And European Economic Area (EEA). PayPal launched tap-to-pay which works with GrapheneOS but has very limited regional availability. Many European banks provide working tap-to-pay with GrapheneOS.
The issue is apps banning using a device not licensing Google Mobile Services or a non-stock OS via the Play Integrity API. Google Pay does this and a lot of banks outsource tap-to-pay to Google Pay instead of providing their own like many European banks. GrapheneOS users in Europe have multiple options. Users in the US often use a smartwatch for this purpose which includes the option of Garmin Pay rather than only Apple Pay and Google Pay.
The choices depend on the region. It would be nice if the Play Integrity API was forced to permit GrapheneOS via hardware attestation verification by regulators. We're pushing for it in Europe.
AFAIU, there's two forms of NFC payment:
- 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.
> ""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.
The company you're discussing is... GrapheneOS itself.
> GrapheneOS Foundation was created as a non-profit organization in Canada in March 2023 to handle the intake and distribution of donations. [1]
> GrapheneOS Foundation has been incorporated as a federal non-profit organization in Canada. It will be used to receive donations to pay developers and pay for infrastructure. It will also help to shield developers from attacks through the legal systems across various countries. [2]
[1]: https://grapheneos.org/history/
[2]: https://x.com/GrapheneOS/status/1638648643363258369
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..
Thanks for you hard work!
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.
https://grapheneos.org/faq#device-support:~:text=The%20follo....
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.
See the response at https://news.ycombinator.com/item?id=44686811.
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.
The same thing could be said about any hardware. Pixels receive by far the most privacy and security research of any devices. They're by far the most secure Android devices and the only ones providing competitive security with iPhones. They're the only devices with even a reasonable level of security combined with proper alternate OS support. Our hardware requirements are listed at https://grapheneos.org/faq#future-devices. These are very reasonable requirements for industry standard security features, standard updates and the ability for GrapheneOS to use those standard security features. There are other devices with all the major features listed there but not the ability for GrapheneOS to use all of them. Updates are a major issue for all non-Pixel Android devices including the ones advertising lengthy support.
GrapheneOS is working with a major Android OEM towards their future devices providing the expected hardware-based security features and updates, unlike their current devices. The purpose of GrapheneOS is not specifically avoiding Google but if you want hardware from another large tech company to use with GrapheneOS, you'll have that option. The initial goal for these devices is providing a similar level of security and long term support to what we already have with Pixels. In the longer term, we want to have add hardware-based security features unavailable on Pixels or iPhones along with hardening below the OS layer.
For now, Pixels are the only viable option for us to use. We're actively working on changing that but we're not going to simply greatly lower our standards and support devices where we can't adequately protect users. There's no evidence of any backdoor and it's contradicted by how exploits are developed and used. There is plenty of evidence that other devices lack comparable security.
https://discuss.grapheneos.org/d/14344-cellebrite-premium-ju... shows an example where only the Pixel 6 and later / iPhone 12 and later have brute force protection which holds up against the most sophisticated company developing forensic data extraction tools. We have access to more recent documentation showing the same thing.
Why do governments buy exploit tools from NSO, Cellebrite, etc. and develop their own if they supposedly have backdoors in devices? Why would using a device from Samsung or Sony protect against it if they did?
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.
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.
They write about their reasoning and criteria for device support here, for example: https://grapheneos.org/faq#future-device.
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.
Which they don't have under Graphene OS - they are the same as any other service you could write.
Yes, thanks for pointing that out. I meant they get all that on the stock OS, but didn't make that clear.
So what computer you use which is 100% open-source?
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.
> If it's done on the baseband processor, no.
The baseband firmware is not obfuscated and people can/do analyze the cellular protocol and how it functions. Which devices receive more privacy/security research than Pixels do? Which devices avoid trusting multiple companies making the hardware? Nothing. Similar things could be said about any hardware we supported, but all the other available options supporting using another OS would be far less secure and unable to provide what GrapheneOS offers. Core features would be missing elsewhere.
We're working with an OEM to have their future devices meet our requirements and provide official GrapheneOS support, but how would that change anything? It's another big tech company making devices. What do you think is special about Google and what reason is there to think they would be putting a backdoor but other companies wouldn't?
> I believe grapheneos has some sort of band band processor isolation, but I'm not sure exactly how it works.
Isolation for the radios is a standard security practice on most modern smartphones. GrapheneOS improves the security of the isolation through hardening the drivers and services against exploitation after exploiting the radio firmware.
> 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.
The CPU, GPU and many other components in laptops, desktops, tablets and smartphones are closed source hardware with closed source firmware. Wi-Fi and Bluetooth are implemented with a separate processor and operating system. There's nothing about that specific to cellular and it's a misconception that it's different from other components in this regard. Modern computers have a bunch of processors and little operating systems across a bunch of components. Many people have the wrong idea that it's somehow specific to a few things like AMD PSP, Intel ME or cellular radios when in reality that's just how things are at a hardware level across many components. Cellular radios are normally an isolated component.
Cellular can be used to detect location, but so can Wi-Fi and Bluetooth. Wi-Fi is the main way network-based location works. Most Wi-Fi networks are from ISP routers and some even have an official way for other subscribers to use it.
Cellular doesn't need to be left enabled all the time. There's airplane mode. Using cellular is an option. GrapheneOS runs on portable computers with support for Wi-Fi, USB ethernet, etc. too not onlyg cellular.
See the response at https://news.ycombinator.com/item?id=44686895.
+1. It is kinda sad that folks seem to have lost critical thinking or even just some plain perspective on things.
They hear their favorite influencer spout something, and they parrot it everywhere. Google bad, hurr durr.
See the response at https://news.ycombinator.com/item?id=44686895.
See https://news.ycombinator.com/item?id=44686811.
Please don't copy-paste comments (https://news.ycombinator.com/item?id=44686811).
Linking is fine, as you did here: https://news.ycombinator.com/item?id=44686876.
It had some changes to what was written due to a different context, but I've changed it to a link.
Yeah, I appreciate that that happens sometimes. Probably the best thing is to link to the original comment and then add the diff in the new context.
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.
Perfect is the enemy of good.
You're worried about Google hardware but your requirement for a phone is that it must have Google Pay? Bizarre.
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).
How is it a black box? You can get the firmware trivially.
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.
I believe spam detection in the Google Phone app does work on GrapheneOS.
For spam, install their sandboxed Google Play, and then install Google's Phone and Speech Recognition & Synthesis apps. For SMS/MMS/RCS spam, you'd use an app supporting blocking (e.g., Google Messages).
I imagine that Hold For Me works if you also install the Google app and whatever other dependencies.
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.
[1] https://discuss.grapheneos.org/d/475-wallet-google-pay/4
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.).
Curve NFC payments work for me.
I love GrapheneOS. The only "issue" I had is that you are actually responsible for your own device, including taking backups.
Unfortunately my home server, which I was using for backups, was flooded and before I replaced it my phone died and I lost a lot of data...
you can always store encrypted backups to cloud storage
True, but unfortunately Proton Drive, which I use for "cloud" storage, does not supported the storage API that GrapheneOS' SeedVault supports for backups
I've been interested in Graphene OS, but being limited to just the Pixel phones is kind of lame. Have a Galaxy A55 I'd have liked to try it with.
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?
Pixel 5 should only be used to preview what GrapheneOS provided prior to October 2024 when Android 15 was released and we migrated to it. It's an end-of-life device and therefore lacks driver and firmware updates. We were able to provide some of those updates past the end-of-life, but not most, and we recommend against using it. We show a notification about it being an insecure device at boot. We continued providing all of our updates and the Android updates for it until the release of Android 15, at which point we shifted to supporting it via a legacy extended support branch based on Android 14 QPR3 with backported AOSP patches and minor fixes of our own. Our support for the Pixel 5 has been winding down further since it's increasingly insecure and we don't want people to use it based on us still providing updates. A Pixel 5 works as a way to try out outdated GrapheneOS but that's about it.
Using GrapheneOS on it would be more secure than the stock OS but it's going to be quite insecure regardless of the OS so we'd recommend just not using it. The intention of our extended support prior to Android 15 and then legacy ex trended support following Android 15 was harm reduction for people unable to afford a new device yet. That's essentially over now. We just didn't remove it from the site yet to avoid complaints. It informs people that it's an insecure device at boot so it's better than people getting misled into believing the alternate OS they've put on it keeps them safe when it doesn't.
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?
Yes, Vanadium (or any browser based on the system WebView) is going ot be up to date and as secure as it gets on a mobile OS.
I only mentioned NFC because you mentioned Google Pay.
That's interesting. Thanks for the information.
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!
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!
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.
Related:
Cops say criminals use a Google Pixel with GrapheneOS – I say that's freedom
https://news.ycombinator.com/item?id=44658908
Cops in [Spain] think everyone using a Google Pixel must be a drug dealer
https://news.ycombinator.com/item?id=44473694
ICEBlock, an iOS Exclusive
https://news.ycombinator.com/item?id=44672521
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:
https://github.com/GrapheneOS/os-issue-tracker/issues/1174
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.
Thank you very much for your work here!
This should be higher up.
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:
https://github.com/GrapheneOS/os-issue-tracker/issues/1174
It the Australian emergency number (000). Not sure if they're using the Google Play services implementation of Emergency Location Services.
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.
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.
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...
Check out FUTO keyboard (it's only ok). Or install GBoard, download the language of interest, and then disable network access to it
I'm using Ginger, which works well. Once I used it once, it downloaded the dictionaries, and I could revoke network access.
Why firefox in andriod is "more vulnerable to exploitation" ?
https://grapheneos.org/usage#web-browsing
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.
Vanadium implements per-site content filtering as a usability feature via Chromium's in-built filtering engine [0]. They currently use EasyList & EasyPrivacy filters which are quite popular and also a prominent default in uBlock Origin [1].
[0] https://grapheneos.org/features#vanadium
[1] https://github.com/gorhill/uBlock?tab=readme-ov-file#ublock-...
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.
Currently all the browsers are with ads by default. Not ideal but certainly most don't encounter spyware through ads, unless they're in some spam sites.
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.
that comparison you are pasting in multiple replies has lineageos without micro-g.
MicroG is extremely insecure. Does nobody remember that they used to print your Google password in plain text in the logs?
k but i do not care about an account that i do not have. i only use it for the gms or whatever is called now
"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)
[0]: https://genius.com/Tool-third-eye-lyrics
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.
No evidence provided, as usual.
>No evidence provided, as usual.
You should watch Rossmann's video on Linus - he has a habit of doing these hit pieces.
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.
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.
> > 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...
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).
Happy to be convinced otherwise.
> The GOS could snoop on their users and turn into malware only if it figures out that this is Rossmann's phone.
Well, yes, but not really. What you're saying could be true if the OS wasn't open source. It's not some small OS that nobody knows about. There are forks of the OS, there are other projects that selectively copy code/commits from GrapheneOS, there are security researchers who pay attention to its development. There are also people who reproduce and verify builds. It's just not possible for that kind of code to be snuck in there.
This section of the website about whether GrapheneOS is audited is also helpful https://grapheneos.org/faq#audit
> 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.
If you pay attention to what they're responding to, you'll find that a lot of that is in response to something they said, clarification about inaccuracies in news articles, etc. The official accounts are also followed by many of the OSes' users, so some posts are for them too if certain things are being talked about in the community.
> 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).
I personally prefer quality over quantity. GrapheneOS developers take a long time to develop new features, test them, rewrite them, and it goes on and on until they have a resulting feature that is very high quality. They also have to keep in mind how much they're adding/changing so features and changes can be ported quickly when there are new upstream releases. Updating quickly is very important for security. Leaving vulnerabilities unpatched for months is not acceptable for a project and users who value security. The same can't be said of LineageOS or /e/OS. They're slow to update, roll back security, etc.
> 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.
https://github.com/GrapheneOS/releases.grapheneos.org https://github.com/GrapheneOS/platform_packages_apps_Updater
> First, he is under no obligation to spend hours learning how GOS updates
That literally takes a few minutes to look up, it's all really well documented on the official website. https://grapheneos.org/faq#default-connections
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.
> That literally takes a few minutes to look up, it's all really well documented on the official website. https://grapheneos.org/faq#default-connections
Again, that is beyond the point. The developer going rogue (for arbitrary reason) and turning the code malicious is not impossible.
> That literally takes a few minutes to look up, it's all really well documented on the official website. https://grapheneos.org/faq#default-connections
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).
> Other people don't think like you, they don't have to think like you.
I'm quite certain that there are more people than just me, who think that someone with close to two million subscribers on YouTube should fulfill due diligence by doing some basic research and at least read the extensive official documentation that's provided, before putting out a video with serious allegations and a very high potential of harming someone's reputation. I would go further and say that it was his intention of harming the project's reputation, but that's just my personal opinion. It's objectively clear though, that this is a very low quality video full of baseless speculation, and severely lacking any technical understanding and knowledge.
> What "absurd" claim did he put out exactly ?
His speculation about targeted malware in the OS.
This is exactly the same as going to a restaurant, having an argument with the owner, and then claiming that they might be putting poison in the food, even though there's absolutely zero evidence or anything that might indicate that, solely because you had a disagreement with someone and now want to harm their reputation.
> It's objectively clear though, that this is a very low quality video full of baseless speculation, and severely lacking any technical understanding and knowledge.
"Baseless" could not be further away from the truth. You literally have the GOS developer messages coming in live while he rehashes frivolous accusations and threatening to exposing him. To claim objectivity, when you seem to cherry pick the parts of the video that would (loosely) fit your narrative. Where is your evidence that Rossmann is in anyway associated to harassment campaign against the project ?
> This is exactly the same as going to a restaurant, having an argument with the owner, and then claiming that they might be putting poison in the food, even though there's absolutely zero evidence or anything that might indicate that, solely because you had a disagreement with someone and now want to harm their reputation.
Damn, so close, you were almost there. A more accurate analogy you could have come up with, had you actually critically listened to Rossmann's argument in his video. Yes, it's like going to a restaurant and having a disagreement with the cook, for the latter to explicitly threaten to harm onto you. At that point, is it that far fetched to think he might poison the food ? When you know he has full control over the kitchen ?
You can disagree with Rossmann perception of the actual threat, but you should at least admit that it is not absurd for Rossmann to think that someone who demonstrated such irrational behavior might attempt to harm in through the means at their disposal, among which introducing malicious code. It might be unlikely given what we know about software dev, but it is not impossible, and for Rossmann, that is the only thing that matters at the end of the day.
Moreover, the GOS dev himself clearly stated he would "publicly expose him" (At 2:14 in https://youtu.be/4To-F6W1NT0?t=134 "and there will be information published about your (Rossmann) attacks on me in support of an abusive person). Why the double standard ? That GOS dev can go around dishing out "reputational harm" but his targets doing the same is not fair game ?
At this point, Rossmann did him a service by publishing everything himself. As far as any reputational harm is concerned, the GOS developer essentially brought it on himself. Could have dropped back when they had the fallout in September 2022, as per the chat logs (<https://www.swisstransfer.com/d/d75ff782-4a7d-4497-b04e-edd1...>) ...
> I would go further and say that it was his intention of harming the project's reputation, but that's just my personal opinion.
Sure, "harm the reputation of the project" when he was proactively giving them no string attached grants, spreading the word, and giving them an opportunities to tell their side of the story ...
> I'm quite certain that there are more people than just me, who think that someone with close to two million subscribers on YouTube should fulfill due diligence by doing some basic research and at least read the extensive official documentation that's provided, before putting out a video with serious allegations and a very high potential of harming someone's reputation.
Then in the first place, perhaps the cyber security geniuses who built a privacy and security oriented OS for smartphone could do the due diligence of gathering and presenting actual evidence of Rossmann implication in the alleged harassment campaign before before posting multiple accusatory statements across their socials media "with serious allegations and a very high potential of harming someone's reputation" ?
>> It's objectively clear though, that this is a very low quality video full of baseless speculation, and severely lacking any technical understanding and knowledge. >"Baseless" could not be further away from the truth.
You yourself have even admitted that while it may not be true that he can be targeted, you make excuses for Rossmann saying he's a "layman when it comes to software". So, yes, it is baseless.
> it's like going to a restaurant and having a disagreement with the cook, for the latter to explicitly threaten to harm onto you. At that point, is it that far fetched to think he might poison the food ? When you know he has full control over the kitchen ?
This is a horrible metaphor because an open source project and the resulting OS is nothing like that. Better analogy would be that all the customers can watch the chef while they work, they all share the same food, and there are even cameras there for the world to see what the chef is doing in real time.
> You can disagree with Rossmann perception of the actual threat, but you should at least admit that it is not absurd for Rossmann to think that someone who demonstrated such irrational behavior might attempt to harm in through the means at their disposal, among which introducing malicious code.
If he had any integrity, he would have retracted that part of his video _at least_ when people pointed out that it wasn't true that he could be targeted. But as far as I know, he hasn't.
> Then in the first place, perhaps the cyber security geniuses who built a privacy and security oriented OS for smartphone could do the due diligence of gathering and presenting actual evidence of Rossmann implication in the alleged harassment campaign before before posting multiple accusatory statements across their socials media "with serious allegations and a very high potential of harming someone's reputation" ?
Anyone who thinks for even a moment can see what happened here. Someone tried to murder Daniel 3 times, he was upset about that and with Rossmann, he talked to Rossmann, Rossmann _records_ it as it's happening knowing full well what he was doing (which I'd argue is quite scummy), and releases the video complete with inaccuracies about the potential of being targeted. Not to mention he has a verified Kiwi Farms account, which anyone who knows the history of that site can draw their own conclusions. It's very easy to see what's all right out there in the open.
Btw I reread all the emails exchanged by Rossmann and Micay (I had already read them back when they were released, but that was over 2 years ago), and I don't see how anything Daniel Micay said would be incorrect. Moreover, I found it quite alarming, how Rossmann addressed exactly zero of Micay's actual points, and then tried to distract from the entire situation with manipulative tactics and by trying to discredit him through his baseless assumptions about Micay's mental health. These leaked emails don't prove anything, other than Louis Rossmann being ignorant and manipulative.
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.
> after his mental illness became clear.
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.
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.
So rossmann literally feared of a patch that was like this getting into graphene
if (user is rossmann) {
}makes me think who is paranoid here.
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.
> mentally unstable
It's not appropriate for you to be saying these things.
> 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.
This makes no sense. GrapheneOS is an open source project and anyone can look at the changes made by the project. Even the OS is reproducible and people do check that, apparently, so GrapheneOS would be caught if they were making changes. Like I even found this repository just now after a quick search https://github.com/lucasbeiler/reproducible-builds-grapheneo...
GrapheneOS isn't just some random OS that nobody has heard of. There are lots of eyes on it, so sneaking some backdoor into the OS would be very difficult and extremely stupid. One misstep and the project would be gone. Do you really think Rossmann is worth that? I don't.
> 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.
I've already pointed out in other comments that he had no good reason to fear a targeted update. It's just not possible. He should know that by now, but as far as I know he has never retracted that part of his video.
> 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.
There are a couple of comments in response to my own saying basically the same thing, so I'll do the same...
Rossmann shouldn't be excused for making his harassment video about Daniel because he doesn't understand how things work. Anyone who bothers to think about it for a moment would understand that someone who had been swatted 3 times by a crazy person spamming community chat rooms with illegal content would be extremely upset. Someone tried to _murder him_ and was trying to destroy the project, and then this video comes out leaking a private chat, and Rossmann portrays him as crazy? Rossmann knew what was happening and then his first thought was to start recording? How is that justifiable?
You confessed you are a Rossmann fan in another comment, but even a fan should be able to see what had gone on here...
> Expecting a layman to know that is not reasonable.
And you are defending the inaccuracy in his video saying he's afraid of being targeted when it's not even possible, and your excuse for him is that he doesn't understand. There is no excuse for his video in the first place, but to also add this falsehood that he even can be targeted is extremely damaging for a project prioritizing privacy and security. And yet even though I'm sure he knows this now, as far as I know he hasn't retracted what he said. I don't think he cares about accuracy. Among other things, he's a YouTuber and he got views and attention, so I guess he got what he wanted at the expense of someone else during an extremely trying time. I don't think that's justifiable, I think it's scummy.
> If anything, even after that video, he kept recommending GOS whenever he talked about privacy.
Doesn't excuse what he did.
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).
Edit: some clarifications.
> 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).
There are a couple of comments in response to my own saying basically the same thing, so I'll do the same...
Rossmann shouldn't be excused for making his harassment video about Daniel because he doesn't understand how things work. Anyone who bothers to think about it for a moment would understand that someone who had been swatted 3 times by a crazy person spamming community chat rooms with illegal content would be extremely upset. Someone tried to _murder him_ and was trying to destroy the project, and then this video comes out leaking a private chat, and Rossmann portrays him as crazy? Rossmann knew what was happening and then his first thought was to start recording? How is that justifiable?
You confessed you are a Rossmann fan in another comment, but even a fan should be able to see what had gone on here...
And you are defending the inaccuracy in his video saying he's afraid of being targeted when it's not even possible, and your excuse for him is that he doesn't understand. There is no excuse for his video in the first place, but to also add this falsehood that he even can be targeted is extremely damaging for a project prioritizing privacy and security. And yet even though I'm sure he knows this now, as far as I know he hasn't retracted what he said. I don't think he cares about accuracy. Among other things, he's a YouTuber and he got views and attention, so I guess he got what he wanted at the expense of someone else during an extremely trying time. I don't think that's justifiable, I think it's scummy.
This is on a level of "5G causes autism" understanding of the topic. Maybe learn how reproducible builds and cryptographic signatures work.
> This is on a level of "5G causes autism" understanding of the topic
That sums it up perfectly
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.
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.
…you haven’t provided any sources at all.
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.
Feel free to peruse and make you own opinion.
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.
All I said is sourced.
As best I can tell, you've done nothing more than brigade a thread with odd claims about the GOS developer, sourcing from an interaction with a known drama YouTuber/KiwiFarms associate.
The people you've had respond to you in this thread, who likely have more intimate knowledge of what actually happened, have done a better job of breaking down this stuff - so I'll just defer to them.
> I do provide sources.
You provided exactly 0 sources in all of the comments I've seen posted by you so far.
> Showing his true colors = not accepting that there is an evil conspiracy and asking for proof.
"Evil conspiracy"? You say that someone else is paranoid and yet you are saying things like this? It's kind of ironic.
> You are completely brainwashed
Okay. If you say so.
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.
Feel free to peruse and make you own opinion.
I've been using graphene since 2 weeks. It's been great. I'm only missing 1 feature: auto call recording.
Not automatic, but the GrapheneOS dialer supports call recording out of the box.
During a call, drag your buttons and they will scroll. The call recorder is the 7th button.
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.
Note that the author of the article has now added "corrections" :
Corrections/elaborations on some points : https://lwn.net/Articles/1031454/
Source: https://grapheneos.social/@GrapheneOS/114914602970489632
> Our community manager has provided a response to the recent LWN article on GrapheneOS with important corrections and context. The article had significant inaccuracies about the history of GrapheneOS, our organization and the details of what we provide. [.................]
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.
I want Graphene OS on a non-Google compact smartphone.
Not "pixel compact", but the size of an iPhone mini.
GrapheneOS "had" to reply to this article because they weren't happy with it's portrayal of events and LWN refused to edit a live article.
Par for the course with GrapheneOS. They always seem to take a good thing said about them and not be satisfied.
https://x.com/GrapheneOS/status/1948811620047536316
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!
Check https://grapheneos.org/donate
Really feel a similar sentiment to a lot of others in the comments! I'm enjoying the recommendations other shared here. I _think_ this follows the rules of conduct for HN but let me know, I recently brained dumped about the following on my blog about the general experience setting up GrapheneOS: https://blog.matthewbrunelle.com/i-picked-a-really-weird-tim...
My main complain by far to LineageOS is the necessity to wipe everything for major releases on my S10. That's not possible every year.
What about Graphene ? Can I get 5 years of updates without needing to wipe the phone ?
> My main complain by far to LineageOS is the necessity to wipe everything for major releases on my S10. That's not possible every year.
Are you sure that you are not just misinterpreting the upgrade instructions?
For the S10 a mandatory wipe-on-upgrade has last been the case when upgrading from versions _older than LineageOS 21.0_.
During the time where LineageOS 20 was the current version there was no requirement to wipe listed at all, so presumably it didn't exist then.
> For the S10 a mandatory wipe-on-upgrade has last been the case when upgrading from versions _older than LineageOS 21.0_.
Ah, that might be it. My current version is 21.
> If your device is running LineageOS version older than 21.0, wipe your data partition (this is usually named “Wipe”, “Format”, or “Factory reset”) .
https://wiki.lineageos.org/devices/beyond0lte/upgrade/
Yes ! Thank you, I can upgrade to 22 without wiping.
Just did the update. Thank you again.
Yes, GrapheneOS has always offered OTA updates via the System Updater app. https://grapheneos.org/usage#updates It's set up to download and install updates automatically by default. Alternatively, you can install a signed update package via adb sideload. https://grapheneos.org/usage#updates-sideloading
Both the update client and the backend are open source, just like the rest of the system: https://github.com/GrapheneOS/platform_packages_apps_Updater https://github.com/GrapheneOS/releases.grapheneos.org
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.
The submission is a bit old but let me try anyway since I see some user claiming to be Graphene community manager here. Let me first reiterate that GOS is an amazing project and that I am super grateful for your work. That said, I think the #1 missing feature is the lack of a robust backup solution. Las time I checked, there was an ongoing discussion about shipping an ad-hoc backup system for GOS. ANy uodate on this? Thanks!
I've been rocking it on mobile for a while, and went for a tablet (LineageOS there previously) this month.
The only real option for privacy and security which isn't swiss cheese.
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.
See https://news.ycombinator.com/item?id=44687530.
> Although it is conterintuitive to use a Google device to get away from Google
The purpose of GrapheneOS is privacy and security, not specifically avoiding Google, which is not what privacy is about overall. Many companies including Android OEMs have worse privacy practices.
> Just stay out of the radar of the leadership, they can be a bit abrasive, for the lack of a better expression.
There are a lot of ongoing attacks on the GrapheneOS project and our team including through fabricated stories and spin. People should look into the actual verifiable facts and look at who is being targeted with harassment and bullying. We defend ourselves from this including debunking inaccurate claims about the project and our team.
Thank you for the warning.
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.
Sweet, I think I'm sold on giving grapheneOS a shot. Thanks!
Definitely worth a try !
I wonder how long it would take them/grapheneOS to support the new Pixel…
They have been usually pretty fast !
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'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.
Fairphones lack proper security patches and OS updates from day one. /e/OS makes this substantially worse compared to Fairphone's own OS. Fairphone tends to lag 1-2 months behind on Android's standard partial security backports and a year or more behind on yearly OS updates. They skip the monthly and quarterly releases. Fairphone 5 uses the Linux 5.4 LTS branch which will be end-of-life in December 2025 with no plan to move away. Older Fairphones use end-of-life kernel branches.
Here's information from the author of the divested projects about /e/OS including data on updates from 2021 up until late 2024:
Issues with /e/OS: https://codeberg.org/divested-mobile/divestos-website/raw/co...
ASB update history: https://web.archive.org/web/20241231003546/https://divestos....
Chromium update history: https://web.archive.org/web/20250119212018/https://divestos....
Chromium update summary: https://infosec.exchange/@divested/112815308307602739
For the Chromium update summary from July 2024, note 128/135 was shipping each update on a given update path. /e/OS only shipped 12/135. They did not ship most Chromium security updates and skipped most releases. They're still skipping many releases and have significant delays for the ones they do ship.
Here's an article from another privacy/security researcher on /e/OS covering some of these issues:
https://www.kuketz-blog.de/e-datenschutzfreundlich-bedeutet-...
As documented there, /e/OS has their own invasive services including user tracking in the update client. https://community.e.foundation/t/voice-to-text-feature-using... is another example where /e/OS sends user data to OpenAI without consent for speech-to-text compared to Apple doing it locally by default and Google at least supporting doing it locally and encouraging enabling it.
There's a third party comparison table at https://eylenburg.github.io/android_comparison.htm with a privacy and security focus. It doesn't currently cover invasive services added by operating systems or privacy/security regressions beyond patch delays though. It covers what is done with most of the standard AOSP services and how Google service compatibility is handled.
> 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.
The purpose of GrapheneOS is providing a high level of privacy and security. This requires secure hardware/firmware with important hardware-based security features and driver/firmware patches. Using a Fairphone with /e/OS is nearly the direct opposite of GrapheneOS.
> Alternatively, there is the iPhone but I do like fdroid and the more open nature of android.
An iPhone would be a far better choice for privacy and security than anything with /e/OS.
I'm secretly hoping my iPhone will spontaneously explode so I can justify buying a pixel for this
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
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.
> 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!
Android has a standard system back navigation gesture based on the previous system back button. Apps integrate support for it. Chromium disables their back/forward gestures when using the modern gesture navigation in the OS. It would have made sense to have a forward gesture but Android never had that as something apps had to implement so it would only work in a small subset of apps and would be generally unavailable, which would be confusing.
Phone app has a button for ending the call. It's our fork of AOSP Dialer with minor changes including UI improvements. Calculator, Clock, Contacts, Gallery, Keyboard, Messaging and Phone are AOSP apps which we need to overhaul or replace. These look and function the same way Google's apps used to but are outdated. They're the open source projects which were abandoned beyond security patches after they forked them off into their own proprietary Google apps. Gallery and Keyboard will likely be replaced while the rest will be overhauled. We know these apps have a bad UI but our focus has been on the core OS instead of apps people can replace. We're beginning to do more work overhauling these.
very interesting. thank you for all of that information and the work you do. maybe one day i can contribute to the UX without being an HN cynic!
That project background reads suspicious as all hell, but then the thing does do what it says on the tin from all the news I see, so go figure.
Hi, GrapheneOS community manager here.
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:
-https://github.com/GrapheneOS/platform_manifest/forks?includ...
-https://github.com/GrapheneOS/platform_bionic/forks?include=...
-https://github.com/GrapheneOS-Archive/legacy_bugtracker/issu...
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.
Did you look at the links?
> Fuzion24 / platform_manifest Created 10 years ago Updated 10 years ago
Ah sorry, might have been unclear: by background, I meant the current governance and contributions situation they describe in the post.
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.
I really hope this project will never die.
I know you talking about my hidden profile. But let say you have a banking account you don’t want people to find out.
Currently you can only keep it on the main profile or any other secondary, which are easily visible.
With my approach you can minimise 99% of the risks for most users.
And even so, you can have 2 hidden profiles. So you can always show the decoy hidden profile.
Does GrapheneOS firewall provide port forwarding or is Netguard required
This is almost enough to make an Apple fanboy switch to android. Maybe I’ll get a second phone just to try it out. Which model would be best?
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.
Battery life improved a lot with the 9th gen Pixels other than the Pixel 9a due to the dramatically more efficient cellular radio. Set it to "4G" or the GrapheneOS added "4G only" as the cellular network mode and you should save a lot of battery life compared to having 5G enabled all the time. Battery life heavily depends on the apps, network and overall configuration. It's easy to end up with bad battery life with lots of apps doing their own push, etc.
GrapheneOS users tend to avoid using Google services when possible and this has a battery life cost when using apps like Signal with their own push systems. In the case of Signal, Molly is a fork with UnifiedPush support that's more efficient but it requires running a server to convert FCM to UnifiedPush since Signal doesn't support it.
Anything 8th gen and later would be best, as those models support MTE which is a huge security feature not present on 6th or 7th gen hardware.
Our recommended devices can be found here:
https://grapheneos.org/faq#recommended-devices
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?
This does not make sense at all.
> 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.
> Phones -are- optional and if you think otherwise you might be an addict.
Smartphones are small portable computers. You're using a similar computer to make posts on social media platforms including Hacker News.
> It is better in one way: a reasonably stable person holds the keys to the kingdom.
Repeatedly claiming that I'm insane, schizophrenic, delusional, etc. is not a reasonable criticism of GrapheneOS. I'm clearly none of those things. I've been targeted with attacks including harassment and tons of fabricated stories for years beginning with my former business partner and his associates. You thoroughly discredit yourself by going as far as baselessly claiming that I'm schizophrenic because you don't like the way I've tried to defend myself from these attacks.
The lead developer of CalyxOS (cdesai) was a Copperhead employee directly involved in the 2018 takeover attempt on GrapheneOS. CalyxOS itself directly originates from the takeover attempt on GrapheneOS. The people involved demonstrated their lack of ethics through their participation in the attacks on GrapheneOS and partnerships with people involved in it. You've been attacking us for years alongside them. CalyxOS exists because of this takeover attempt. It's a non-hardened OS which was created by heavily using GrapheneOS source code and documentation without most of our privacy and security features.
I am not qualified to actually diagnose you with anything, but I think you are brilliant with normally well reasoned threat modeling, yet also you seem stuck in a revisionist history narrative that people were trying to rip off or steal from GrapheneOS, when I was there for a lot of it, in frequent contact with all main parties involved. The other projects simply existed with different goals that sometimes referenced or forked code you chose to open source (which everyone appreciates). The Copperhead shady licensing situation as I understand was understandable to walk away from, but the constant citing of conspiracies and sock-puppet campaigns that never happened and your hostility to CalyxOS, F-Droid and others who are good community actors was where a lot of people including me felt you lost the plot and were not being rational. The "takeover attempt" narrative never happened and every time you say it did without evidence you hurt your credibility. It is an incredible conspiracy accusation that merits proof, or you will continue to be called delusional. I do always make an effort to separate these seemingly irrational views with otherwise well reasoned security engineering work.
The primary thing we disagree on in a pure objective security engineering capacity is you feel it reasonable that a single person, you, can be trusted to resist coercion or manipulation to hold the signing keys that would allow pushing any code to the phones of a lot of highly targeted and vulnerable individuals. Otherwise I actually normally agree GrapheneOS has made the best effort defense calls it can in a very broken and proprietary ecosystem. Use open stuff where you can and where you can't try to put up IOMMU walls. I get and respect the pragmatism here. I do similar in AirgapOS and other projects.
I however absolutely can never recommend trusting centralized/proprietary software supply chains in areas where dramatically more open and accountable solutions already exist, which is why I do not actually use or recommend CalyxOS or GrapheneOS for high risk use cases and instead full source bootstrapped a Linux distribution from scratch that avoids any trust in me as the founder by design.
For low risk use cases where users simply don't trust Google or the stock phone malware, LineageOS or CalyxOS is just fine as they remove this, and I am more inclined to support cdesia/CalyxOS which at least attempts basic signing, and trust cdesia as a keyholder when someone really wants to use Android purely because of his peace-keeping personality that is normally very receptive to criticism, and is never hostile to anyone that forks their code for use in other projects as you have a history of doing, but ultimately again, I don't actually use or recommend CalyxOS or GrapheneOS for most people for most use cases.
If forced to use a mobile device again I would probably fork GrapheneOS, remove all the proprietary bits I can, LTE, bluetooth, etc be damned, and sign it myself only for my own use, until I could develop an quorum enclave controlled signing scheme and then offer that.
If you were to agree to take on quorum controlled signing of reproducible builds, then there is no central trust in you, and all my primary arguments against GrapheneOS go away and GrahpheneOS would be leaps and bounds better than CalyxOS by any technical measure I am aware of.
If you put aside any dislike of me, objectively, removing trust in a single person makes you and the project and users safer, and make it much easier for people to separate your personal views from the stability of the project as a whole.
I could get dementia tomorrow and I am confident the StageX project would continue without me with signatures by other maintainers by design. The team already has made several releases without needing signatures from my key already. This is a proven strategy now, not just a theory I parrot to try to win arguments.
GrapheneOS, for all its high risk users, deserves to be protected from the failing of any one human or build machine.
I'll let you have the last reply as this will go on forever otherwise. You know how to contact me if you ever want to discuss any of this privately.
> I am not qualified to actually diagnose you with anything
You should stop calling be insane, delusional, etc. It's quite easy to stop.
> yet also you seem stuck in a revisionist history narrative that people were trying to rip off or steal from GrapheneOS
No, I'm not doing that. The fact that they built on our code while trying to undermine us with misinformation and numerous forms of attacks is what makes it wrong. Calyx knowingly spread and supported misinformation about GrapheneOS and myself. They welcomed, tolerated and worked with people involved in harassment along with frequently participating in it. You do it yourself as you've demonstrated here so of course you don't see it for what it is or think it's wrong.
> but the constant citing of conspiracies and sock-puppet campaigns that never happened
The harassment and their involvement in it happened and continues to happen. Your involvement in it is real and continues too. There's no conspiracy. It's plain for all to see you repeatedly calling me insane, delusional, schizophrenic, etc. and personally targeting me in similar ways over and over. You're just one of many people doing it. That is the harassment, which clearly does exist and you participate in it including in this thread. Calyx and their community are heavily involved in it.
> your hostility to CalyxOS, F-Droid and others who are good community actors
CalyxOS and F-Droid both have multiple people who were involved in the takeover attempt and supported their attacks on us, including the lead developers of both projects.
> a lot of people including me felt you lost the plot and were not being rational
It's factual information, and it's you not being rational about it.
> The "takeover attempt" narrative never happened and every time you say it did without evidence you hurt your credibility
It is exactly what happened. My former business partner tried to take over my open source project against the terms of our agreements. The project was started prior to the company existing in late 2015 and was very clearly separate from it. This has been confirmed by other people involved and around at the time including the 3rd person involved in forming the company.
> It is an incredible conspiracy accusation that merits proof, or you will continue to be called delusional
My former business partner trying to take over my open source project is what happened and is not a conspiracy theory or delusion.
> I do always make an effort to separate these seemingly irrational views with otherwise well reasoned security engineering work.
My statements and views about this are not irrational.
> The primary thing we disagree on in a pure objective security engineering capacity is you feel it reasonable that a single person, you, can be trusted to resist coercion or manipulation to hold the signing keys that would allow pushing any code to the phones of a lot of highly targeted and vulnerable individuals.
We don't disagree on the concept that it would be nice to avoid trusting a single person with this. Where we disagree is that I do not think your proposed approaches are better or that they actually address the trust placed in many people.
> and I am more inclined to support cdesia/CalyxOS which at least attempts basic signing
Not clear how you think we do not do basic signing.
> and trust cdesia as a keyholder when someone really wants to use Android purely because of his peace-keeping personality
He was directly involved in the very real takeover attempt on the GrapheneOS project at Copperhead. He stood by as Nick repeatedly spread misinformation about GrapheneOS and personally attacked me including regularly covering it up. He has a long history of making false claims about GrapheneOS and myself himself. He's friends with many people participating in harassment towards me and clearly has no issue with it along with openly helping them do it.
> that is normally very receptive to criticism
In reality, no, and they'll quickly shut down conversations particularly involving any of this. You think they'd talk openly about this where someone raises actual things they've done and participated in? No.
> and is never hostile to anyone that forks their code for use in other projects as you have a history of doing
Calyx gained influence over Seedvault, a project written for GrapheneOS by a GrapheneOS user, and has since used that to be hostile towards our users reporting issues there and us for continuing to reluctantly use a project now hostile towards us. They've done the same with other projects. They're hostile towards our users, not only us.
A Calyx contractor recently closed a valid F-Droid bug filed by a GrapheneOS user causing it to wrongly show a warning on GrapheneOS every time it installs/updates an app. It's clearly an F-Droid bug since we use standard Android infrastructure to add our Sensors permission and their bug occurs with the POST_NOTIFICATIONS permission and multiple other past cases of added or split permissions in Android. It's a long term F-Droid bug which has existed for ages. Instead of fixing it, they're keeping incorrect code with no purpose and instead adding workarounds for specific cases found to occur with Android's added or split permissions. There's no reason for F-Droid to be checking that the requested permissions parsed from the APK by them match what the OS considers to be the requested permissions. The APK is verified before it's installed and F-Droid's understanding of permissions not matching Android's understanding is fully expected since it does not handle implementation details. It cannot properly handle it as the OS does because the OS adds and splits permissions this way in future releases, so adding all of the current ones still causes it to break in the future. This used to break automatic updates for GrapheneOS users, but at least now it only displays an incorrect warning. They may change it to break things again. Meanwhile, they falsely claimed we were avoiding doing something about this to hinder F-Droid's compatibility with GrapheneOS when they are blatantly doing that. This is one example of how they misuse their control over projects to cause harm to their own users to hurt GrapheneOS. They've done so repeatedly.
> If you were to agree to take on quorum controlled signing of reproducible builds, then there is no central trust in you, and all my primary arguments against GrapheneOS go away and GrahpheneOS would be leaps and bounds better than CalyxOS by any technical measure I am aware of.
The whole thing is a personal grudge and you hold us to a standard you don't hold other projects to based on it. A substantial amount of resources is required to simply make 1 set of builds. Blocking releases indefinitely any time there's a regression in determinism without any more resources to deal with that or early access to address issues prior to when a stable release comes out isn't going to work. When we're porting to a new release like Android 16, addressing some kind of new bug causing something to be non-deterministic cannot be our priority without early access to the release and resources to handle it. If you truly wanted us to do this then you could have helped us get what we needed to do it, make the required scripts and improve protection against non-determinism getting introduced. Instead you act as if this isn't something we want, when it is, but we aren't willing to break updates with an improper implementation.
It's not clear how you avoid trusting me or the developers doing nearly all of the actual development and code review on GrapheneOS through this though. Reproducible builds combined with checking it's reproducible from other parties does not truly accomplish that. Source code is being trusted either way.
There is someone actively reproducing each of our builds after we make releases. It's fully reproducible but AOSP and other projects do have upstream regressions for this we have to fix on a regular basis. It's not always easy to fix.
> If you put aside any dislike of me, objectively, removing trust in a single person makes you and the project and users safer, and make it much easier for people to separate your personal views from the stability of the project as a whole.
I dislike your false claims about me and your harassment towards me. Most of the few times I've interacted with you for several years have involved you making personal attacks on me and talking about us not providing a reproducible build verification feature which barely any projects provide and which is not practical for a project largely based on AOSP without early access or the resources to fix all reproducibility issues they introduce prior to stable releases.
> I'll let you have the last reply as this will go on forever otherwise. You know how to contact me if you ever want to discuss any of this privately.
I don't think we're ever going to come to an understanding. I simply want you to stop making public personal attacks on me. I'm not showing up in threads about your projects talking about what you've done towards me, but you keep showing up in discussions about GrapheneOS to claim that I'm crazy and delusional. You're doing the opposite of encouraging us to implement the signing feature you want.
I was referring to CalyxOS doing signing over LineageOS which does not (in any useful way), as the two popular operating systems that happen to share a lot of hardware compatibility overlay with GrapheneOS (but admittedly little else in common).
The one point I will take that is fair is to stop trying to diagnose you as that is not my background or place to do. We will likely continue to have wildly different accounting of the same events and the motivations of those involved, but it is on me to not lower my communication standards when dealing with people I find to be extra difficult or extra wrong. Point taken.
I apologize for any and all assumed medical diagnosis related comments about you and I commit to stop making these as I am not qualified to make them. I will also discourage those comments in my communities as I can. We should be better than that.
What I can and will repeatedly say is that you are obsessively defensive about GrapheneOS to the point that all criticism of it or your communication style or use of your code in related projects is regarded as a coordinated attack or harassment campaign when it is simply a lot of people who have independently found your personality impossible to work with in spite of making useful code. So much so that many have taken steps to actively fork things away from you so they do not have to deal with you because your approach puts -their- mental health and desire to work on related code at risk.
This is a real shame things went this way, because so few doing hard and important security work also have strong interpersonal skills.
I am going to try to do better here, and I hope you do the same. It is unlikely we ever be friends but I hope we reach a point where we can make use of ideas or code each other might have been involved in without drama. I am even considering adding hardened_malloc as an optional package in stagex because I still feel this is great work.
I will stay out of threads on your projects unless about something I am actively working on or working with, but I will continue to share my own view of shared events and my issues with trust structures in current Android efforts, including GrapheneOS and your leadership style, when they come up organically by others in my communities.
I hope you are able to take that for the win that it is.
> 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?
CalyxOS lacks the current driver/firmware patches and isn't a hardened OS with similar privacy and security patches. There are plenty of worse options but people are better off using an iPhone.
Hardware and firmware is closed source in general and the complexity of that dwarfs a few dozen closed source driver libraries used on top of open source kernel drivers. Pixels have those libraries built with debug symbols and they're not hard to review. It's not obfuscated code and you're given the function names, etc.
Those few dozen mostly quite small libraries being open source instead of closed source with debug symbols would be nice and is something we want. With an OEM partnership, we can have access to the sources and build them with hardening even without those being open source yet. We can likely include debug symbols just as Google did for the most part on Snapdragon Pixels. Convincing a company like Qualcomm to open source those would be ideal, but it's far from being at the top of a rational list of privacy and security improvements which could be made.
> This does not make sense at all.
You can see he's once again making a baseless claim that I'm schizophrenic, delusional, etc. in his post here as he has done many times before. There's also the baseless claim that I believe wild conspiracy theories. It's not me making unsubstantiated claims about backdoors and proposing approaches to prevent it which disregard the hardware and firmware to focus on the OS having reproducible builds, which would not stop malicious changes hidden at a source code level. I don't think Hacker News should permit baselessly claiming someone is schizophrenic. It's not reasonable discourse, and neither is linking what's clearly harassment content from a Kiwi Farms as happens here regularly. I've never claimed GrapheneOS prevents hypothetical backdoors and certainly wouldn't claim reproducible builds (which we have) can somehow we used to prevent it for the OS.
We can make more use of the reproducible builds but enforcing anything based on it requires early access and more resources to fix reproducibility issues early to avoid delaying security updates. It will not avoid trust in the OS developers and the projects it uses itself. It can only reduce trust in the build infrastructure and people involved. Open source does not prevent backdoors. The small amount of closed source library code for supporting a modern smartphone SoC, etc. is also quite insignificant compared to the overall hardware and firmware complexity. Reviewing those libraries is also quite doable. Open source is not a hard requirement to review something, particularly with debug builds for most of it and no obfuscation. When we find bugs in this code with MTE, we get nice tracebacks with the function names due to the debug symbols. It's hard for us to make our own fixes for it, but not impossible. We would prefer if they were open source, but it's FAR from the most pressing issue and is something SoC vendors could quickly solve if convinced to do so.
> 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.
> Also, you are pretty much factually wrong on a bunch of items on your list.
If you are going to call me misinformed, please take the time to prove it so I can stop sharing information I otherwise have no reason to believe is incorrect.
> There is no 100% open-source hardware, period.
Multiple fully or mostly open hardware computers exist. They just cannot run android.
MNT Reform, Precursor, and Talos II are the top three that come to mind.
Those are lightyears ahead in openess and auditability compared to anything Google produces.
> Multiple fully or mostly open hardware computers exist. They just cannot run android.
No, not really, and there's no reason those can't run AOSP.
> MNT Reform
It has a typical closed source ARM SoC and other components. The chassis and board being open doesn't make all the components open. CPU, GPU, MMU, USB, etc. are provided by the SoC and are closed source as usual. It has closed source hardware and firmware for the SoC along with other closed source hardware and firmware. Not having to load firmware from the OS does not mean it's open hardware and firmware. It's barely more open than other computers for the most complex parts of it.
How is something fully open hardware if the vast majority of the complexity is in closed source components providing most of the functionality? The SoC is just the most complex of these by far.
Why couldn't AOSP be run on a regular ARM SoC used in devices which run AOSP? AOSP works fine on top of the mainline Linux kernel and drivers.
> Talos II
A mostly open source motherboard where you drop in a closed source CPU is not really an open source platform. It's not fully open source itself and the CPUs used with it are not open source. IBM took steps towards open sourcing PowerPC as an ISA and relatively primitive open source cores OpenPOWER core designs exist. However, what's actually available and used with it are closed source CPUs. In theory, there can be open design CPUs for use with it. As a motherboard, it's pretty close to fully open hardware. As a functioning computer, it's mostly not because a motherboard is not a whole computer and is far less complex than the CPU even with a more traditional desktop design with less functionality moved into an SoC.
> Precursor
It has a closed source FPGA as the primary processor and other closed source components. It's far closer to being open source, but it isn't fully open hardware. This is the only one you listed which is anywhere close to mostly open source. It is very far from a powerful modern smartphone device though.
> Those are lightyears ahead in openess and auditability compared to anything Google produces.
The primary SoC in each is closed source. Precursor programs their CPU on top of that closed source FPGA so the CPU is open source in that sense and much closer to being mostly open. It's not the only closed source part of it.
The other 2 examples have a closed source SoC. One uses a regular closed source ARM SoC incorporating far more than a CPU and GPU into the closed source chip. The other depends on a more traditional desktop style closed source CPU from IBM outsourcing more to the motherboard.
> GrapheneOS (like all modern AOSP based ROMS) can literally not function with just the open source code.
It does not inherently require any closed source code or hardware. Real world hardware is closed source and requires tons of closed source firmware. Not updating the firmware doesn't make it not exist. It would mean it was outdated and missing important security patches. Lots of firmware is updated by GrapheneOS. All of the kernel drivers are open source. Replacing closed source libraries such as the Mali GPU library to use hardware components is something relevant to GrapheneOS and any other OS targeting the same hardware. It's best for the SoC vendor and OEM to be involved in that rather than spending many years gradually assembling it downstream where by the time things work, the device is end-of-life. The hardware/firmware would still be just as closed source after doing all of that.
Ignoring all of our hardware requirements would not result in there being a single device we could support without nearly entirely closed source hardware and firmware.
> He is without question a brilliant security engineer, but we can't ignore his very public Terry-Davis-esqe history of mental illness.
There's no basis for these repeated claims that I'm insane, delusional or schizophrenic. Defending myself from frequent attacks by many people doing exactly what you're doing doesn't make me crazy or an aggressor towards the people doing it. You're demonstrating the ongoing libel, harassment and bullying directed towards me. There's no point in claiming it's a delusional when you've repeatedly engaged in it. Engaging in this in plain sight and pretending it's imagined is ridiculous.
> 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 do not believe any wild conspiracy theories. It's a baseless and dishonest claim. I'm not the one pushing unsubstantiated claims about backdoors and a clearly non-working approach to preventing them. Not having the Mali GPU driver library and similar closed source userspace libraries would not change that the hardware and firmware is closed source and also far more complex.
> 1. they are able to find a device they can run 100% open source code on with no binary blobs
There's no laptop, desktop, tablet or smartphone which is not filled with closed source hardware and firmware. Having some closed source libraries for a Mali GPU driver, etc. which are not obfuscated, generally have debug symbols and can be thoroughly inspected/audited if you want to do that is insignificant compared to the vast complexity of the closed source hardware/firmware.
A device avoiding having a few dozen closed source vendor libraries would be nice but it's still going to be closed source hardware and firmware. It would allow us to cover it with our added compiler-based hardening and much more easily fix or work around bugs we find with our hardening features such as memory tagging. It's something we want and can eventually be a requirement, but not yet. Tensor Pixels greatly reduced how much of this there is compared to Snapdragon Pixels but didn't keep going in that direction especially with Android 16 throwing away a lot of progress.
> 2. The ROM can be full source bootstrapped to mitigate trusting trust attacks.
It's an operating system, not a ROM. Having a standard toolchain build is for reproducible builds and all parts of the toolchain itself can be built from the source tree.
> 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.
GrapheneOS has reproducible builds. There's a community member regularly testing it and publicly reporting any issues which come up in our public development room. A recent example is that Android 16 split up the kernels into 3 groups which we found hard to explain and make sensible for people building it, which they ran into. There are sometimes regressions in AOSP which cause minor reproducibility issues. This community member looks into those to determine what's wrong. There are not currently any known build reproducibility issues which occur regularly. There's no strong commitment from the Linux kernel, AOSP, Chromium, etc. to keeping builds fully reproducible and blocking security updates based on this wouldn't make much sense, particularly with a strict interpretation of it rather than investigating the actual differences and determining if it's even an actual code difference.
AOSP having a regression causing a timestamp to be added somewhere isn't a reasonable justification for blocking security updates. No system without the ability to investigate the cause and determine if it's okay would be reasonable. We would need to finally have early access to new Android releases to test this in advance and have fixes ready to go prior to the stable releases. We do not currently have this early access but will likely obtain it from the OEM we're working with soon. We would still need additional resources to have ongoing testing for this and fixes for any relevant regression that finds. Porting to new releases prior to them being stable and specifically testing this would be needed.
We can't risk introducing a very a fragile system which could result in substantially delayed updates. Our plan for reproducible builds is to provide an opt-in feature where people can select which additional parties they trust to reproduce builds without falling behind significantly. This would solely be for the OS update client and App Store updates. It would not be for other uses of signing such as verified boot which are not designed to handle this. It would a system to verify that signed hashes from other parties have been published for an update. The meaning of that can be defined by these parties reproducing builds, such as how they'll investigate a mismatch and the way they'll determine if it's an issue.
In practice, this would be based on tools we publish for others to use for building and comparing. Similar to the rest, people are trusting the source code and the people who wrote it. Source code is not inherently trustworthy and provides no magical privacy or security properties. Reading the sources does not mean you will find all the vulnerabilities, particularly subtle ones or hidden ones. It clearly doesn't provide that even for extensive audits/review. Why does the Linux kernel have so many serious vulnerabilities being found on a regular basis including ones which are years and even decades old if this approach works?
If you truly believe that I'm insane, why do you think it's reasonable to use code that I wrote or supervise writing as long as the build matches the sources?
> 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.
You use many open source projects with far fewer review. GrapheneOS itself is based on AOSP which uses a huge number of open source projects from a huge number of people. The Linux kernel alone has a massive number of contributors and most code has little review. It's filled with vulnerabilities which are found regularly. https://lore.kernel.org/linux-cve-announce/ provides a very flawed overview of this based on what is backported. These devices are compromised in the real world by exploiting vulnerabilities like many of these. Reproducible builds and checking that others have reproduced builds is not actually going to stop a software supply chain attack in practice, which would work within the constraints and use source code. If one of the projects used by AOSP has a backdoor added to the sources, how do reproducible builds help? We'd just be building the code and the backdoor would be reproducible.
> 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.
Computers have closed source hardware and firmware in general. A few small closed source libraries are not significant compared to the overall complexity of the closed source hardware and firmware. Those libraries are easy enough to review. Pixels have debug symbols enabled for them. Reviewing firmware is a larger scale and much harder undertaking. How do you review the hardware itself? Even if the hardware design was fully open source for the SoC including the CPUs, GPUs, MMU and everything else along with the radios and other peripherals, how would you verify that what a chip manufacturer like TSMC produced matches the hardware design?
> 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.
The lead developer of CalyxOS is a former Copperhead employee directly involved in the takeover attempt on GrapheneOS in 2018. You're talking about someone who was a direct participant in doing shady things for Copperhead's CEO going against the ethics of the open source project the company was meant to be supporting including participating in the takeover attempt and then leaving following it.
He was involved in subsequent attacks on GrapheneOS including similar harassment to what you participate in yourself. CalyxOS does not have current Android privacy/security patches. It's still missing the June 2025 patches for Pixel drivers/firmware. It isn't a hardened OS like GrapheneOS with similar privacy or security improvements, and it doesn't maintain all of the standard security model due to the privileged code they add to the OS.
I wish to use Graphene OS, but I can't force myself to buy a Pixel Phone, I don't like the design.
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.
Didn't try it in a long while, but I remember being able to run the proprietary pixel camera app just fine.
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.
Hi there. GrapheneOS community manager here.
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.
I'd also recommend giving https://grapheneos.org/faq#audit a read through.
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).
However, do you consider yourselves as able to resist a nation-state level adversary with resources dedicated to compromising you?
I think of two things, the Solar Winds build corruption, and putty's mishandling of e521 keys.
What is your vulnerability to a similar disaster, exploited or not?
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?
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.
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.