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.
I am alright with things that allow for improvement, at least in theory
Even more FOSS friendly graphics vendors like AMD and Intel rely on binary firmware.
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...
As opposed to "being free in all senses of the word", which is what the comment was talking about.
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.
With the right hardware choices running blob-free linux is pretty straightforward.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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)
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
https://old.reddit.com/r/StallmanWasRight/comments/1l8rhon/a...
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.
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.
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.
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.
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.
Looks like they are doing what a small company is able to do.
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.
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.
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 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.