[lrvick]

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

[morserer]

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

[strcat]

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.

[matheusmoreira]

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.

[strcat]

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.

[matheusmoreira]

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.

[rtpg]

Was there ever? And is the situation improving or worsening?

I am alright with things that allow for improvement, at least in theory

[couscouspie]

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.

[bornfreddy]

Not sure what the situation is with Librem, Pine and Joola/SailfishOS, maybe those qualify?

[strcat]

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.

[Daviey]

AOSP is coming to an end...

https://old.reddit.com/r/StallmanWasRight/comments/1l8rhon/a...

https://news.ycombinator.com/item?id=44254540

[strcat]

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.

[lrvick]

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.

[strcat]

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

[mixmastamyk]

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

[strcat]

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.

[mixmastamyk]

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.

[A4ET8a8uTh0_v2]

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.

[lrvick]

Replicant was the last time we had fully open Android devices. We have regressed.

[strcat]

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.

[lrvick]

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.

[strcat]

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

[strcat]

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.

[lrvick]

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.

[strcat]

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

[lrvick]

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.

[strcat]

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

[lrvick]

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.

[gf000]

As opposed to using what, hand gestures? There is simply no production ready hardware with non-proprietary software at all.

[const_cast]

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.

[palata]

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

[rst]

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

[lrvick]

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.

[cherryteastain]

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.

[strcat]

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.

[bowsamic]

Indeed, mainline linux distros aren't free software either

[lrvick]

I have run nvidia cards without proprietary drivers for years. Nouveau.

With the right hardware choices running blob-free linux is pretty straightforward.

[Andromxda]

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

[lrvick]

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.

[strcat]

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

[cherryteastain]

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

[Andromxda]

> 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