Notices by GrapheneOS (grapheneos@grapheneos.social), page 3

@lispi314 @maumau @fluffery @kkarhan @BryanGreyson Preventing shipping firmware security patches provides assurance of insecurity. Pretending it does not exist and ignoring the need to apply microcode/firmware security patches does not mean it stopped existing. Blocking updating it doesn't make it stop existing. It's still there, is still closed source firmware and has publicly known vulnerabilities unable to be patched. This is not solving real problems but rather creating bigger problems.

@lispi314 @maumau @fluffery @kkarhan @BryanGreyson It is still closed source firmware if it can't be updated, and closed source hardware doesn't actually matter any less than closed source firmware. It's very arbitrary to claim that not being able to update it due to blocking the update mechanism makes it hardware rather than firmware. It's often possible to undo how it was blocked and still update it anyway. Librem 5 has certain components unable to be updated via OS but they can be flashed.

@lispi314 @maumau @fluffery @kkarhan @BryanGreyson Shipping closed source hardware and closed source firmware with updates blocked takes away a user choice and provides assurance of insecurity. That's not progress and is the opposite of it. Choosing much less secure components with baked in firmware and state which are far less transparent is not progress towards openness either, but yet that is what Purism does with their devices and what the FSF guidelines encourage. It's the wrong direction.

@lispi314 @maumau @fluffery @kkarhan @BryanGreyson If you take a look at the Pixel firmware, you'll find it's not obfuscated and that you can read the code when disassembled. How would it be better to have the code baked into components and inaccessible to users? Open source would be better but having access to unobfuscated closed source code is useful and better than nothing. Requiring the OS to load the code at boot for hardware to function is good for multiple reasons including security.

@lispi314 @maumau @fluffery @kkarhan @BryanGreyson It's not possible to externally improve most of it on a whether or not it's open due to verified boot and signature checks. On a reasonably secure device, the only way you can do that is if there are device variants sold where efuses are not yet burned and you can burn your own signing keys into them or use it in development mode without those security checks, which wouldn't be something we would do on a production device.

@lispi314 @maumau @fluffery @kkarhan @BryanGreyson That requires selling variants of devices with efuses not burned which users can choose to deal with as they want. Selling regular devices to non-technical people that way would be problematic since it implies not having verified boot and other related security features. Also, it's a huge responsibility to have control over those fuses. Do you want to be locked in to using someone's 3rd party builds? Managing keys/builds is beyond most people.

Many companies and individuals are trying to mislead people about the future of GrapheneOS to promote their insecure products and services. GrapheneOS is not going anywhere. We've made it clear we're shipping Android 16 soon and that the supported devices will remain supported.

@lxo @SuperDicq @toatrika @Starkimarm @tris linux-libre removes warnings about outdated microcode. The warnings exist due to known security patches. Nothing about that is misinformation. Many of the security vulnerabilities are public knowledge and that includes ways to exploit them, so it's possible to test for whether they are patched or not separately from microcode versions. Not shipping microcode/firmware updates means not patching vulnerabilities. Removing warnings about it is hiding that.

@jeffcliff @SuperDicq @lxo Open source software is in fact a black box to most people. Even for software developers, they're still trusting the people making it. You're conflating different things together.

The idea that preventing people updating firmware or even preventing replacing it with different firmware is somehow more free is nonsensical. Taking away a capability from users to use as they wish is not giving them freedom. Taking it away doesn't make it freedom respecting or open.

@jeffcliff @Starkimarm @tris @SuperDicq @toatrika @lxo If you want us to respect your views on it, start being consistent by not drawing an arbitrary line where blocking updating firmware/software makes it not count. If you stop doing that the focus could be on making actually open and freedom respecting hardware instead of playing games pretending hardware/firmware isn't proprietary if it can't be updated or that it's not relevant in the same ways. As is it's just unserious and downright silly.

@jeffcliff @Starkimarm @tris @SuperDicq @toatrika @lxo The eventual goal is that we want open hardware, open firmware and open software with a balance of privacy, security, usability and compatibility. What we make today is what we are capable of doing which balancing priorities. Our specific focus differentiating what we are working towards from other projects is serious work on privacy and security. Current software, firmware and hardware has atrocious privacy and security. It is our focus.

@lxo @SuperDicq @toatrika @Starkimarm @tris You are removing security patches and removing security warnings. You are misleading users and tricking them into having insecure devices while convincing them they're better off based on your ideology. You are not fighting for freedom, privacy and security. You are fighting for completely arbitrary rules where blocking people updating components somehow cancels out the fact that they're proprietary. That has nothing to do with what you claim to value.

@jeffcliff @Starkimarm @tris @SuperDicq @toatrika @lxo You want people to trust software on faith alone based on licensing. You also expect them to trust the hardware and firmware on faith alone as long as it doesn't allow updating the firmware. You folks simultaneously promote proprietary hardware/firmware while telling people they can't trust proprietary software. There's no consistency or logic to it. You pretend to care about things you clearly don't to sell people on the strange ideology.

@SuperDicq @lxo Having a Qualcomm baseband on a larger SoC with a CPU running a closed source fork of Android and then replacing that closed source fork of Android with something else still leaves you with a 100% closed source firmware baseband and 100% closed source hardware for both the baseband and overall SoC. Presenting that as open source because a usually non-existent CPU can have the software replaced is promoting closed source hardware and firmware as being something it isn't at all.

@SuperDicq @lxo People who actually want open source hardware and firmware should have a huge problem with projects being marketed as providing that when they don't. Purism presents their devices as being open over and over again which then results in tech media widely claiming their open hardware which they absolutely aren't. Pine64 doesn't do as much of that, but they do a bit of it. People who actually want real open hardware and open firmware should in fact have a major issue with that.

@SuperDicq @lxo Pretending the closed source firmware (and hardware) doesn't exist by leaving it not updated or choosing components which don't require the OS to load it does not make it go away, and does not make it more open. Components with closed source firmware stored on them are not more open than components requiring the OS to load it.

Fighting for having firmware/software updates disallowed is not fighting for freedom. Locked down devices without user control or updates meet your bar...

@sun @Starkimarm @tris @feld @SuperDicq @toatrika @lxo It does very little to get contributions back to the upstream project and ecosystem. That's often true when distributing code to users too. Being forced to give the users the code doesn't mean it's going to get to the upstream project and doesn't mean the code is useful to them.

The main reason developers choose GPL is trying not to get taken advantage of, not the actual spirit / purpose of GPL, and then they often get very disappointed.

@sun @Starkimarm @tris @feld @SuperDicq @toatrika @lxo They're describing what most companies do with GPL code: they use it internally. It's the large companies like Facebook, Google, Amazon, etc. where they have a ton of things like Linux kernel performance improvements they use internally and have no requirement to publish. Google tends to eventually try to upstream stuff but most companies don't. It also takes a very active effort to get it upstream. It's typically very hard to do.

@sun @Starkimarm @tris @SuperDicq @toatrika @lxo The reason most developers chose to use GPL licensing is because they thought it would result in getting contributions back and not having themselves get taken advantage of. It does not actually do that.

Some projects have been moving to non-commercial usage licenses from GPL because they're upset big companies are using their code without giving anything back.

Code also often isn't distributed outside of a company.

@sun @Starkimarm @tris @SuperDicq @toatrika @lxo GPL does not force contributing anything back. It is not the intended / stated purpose. It forces giving the code to the users it's distributed to, not the upstream project. The upstream project can potentially get the code if they can become users of it or if compliance is done by just publishing it publicly but that's not mandatory. The code doesn't have to meet the upstream standards and be at all close to something which could be used.