GrapheneOS doesnt really proactively attack GNU/Linux. What happens is that there are posts on the internet about GrapheneOS or mentioning GrapheneOS in which or under which completely wrong comparisons between GrapheneOS and GNU/Linux get posted. It makes sense that you care to clarify or correct if you spot people are talking about your project and are (intentionally or unintentionally) spreading wrong information about it by making comparisons based on misconceptions or falsehoods.
The thing you link about restricting network traffic doesnt make much sense. GrapheneOS has a proper network permission which other OSes dont have. The outbound traffic restrictions to certain destinations which are being referred to are just a bad approach. You can send the traffic to one server and just process it there and send out to other servers.
You also say :
> Also, if I explicitly don't trust Google with anything, GOS is extraordinarily insecure for me until a new vendor
If thats the case, dont opt for GNU/Linux either given the large code contributions made by Google. Also avoid any software built with LLVM, written in Go, written in Flutter, using Angular, ...
The two "problems" you link arent really huge security issues. How is GrapheneOS having access to the embargoed patches and being able to ship them a security issue? Also the planned sideloading restrictions dont even apply to GrapheneOS. It would only apply to certified OS that license Google Mobile Services. Also, that isnt even a security issue. Its a freedom issue.
> How is GrapheneOS having access to the embargoed patches and being able to ship them a security issue?
This is not the actual issue. The actual issue is that existing patches for a known vulnerability become unavailable, because Google decided so, making GOS potentially insecure. Patches without the source code shouldn't be trusted.
> It would only apply to certified OS that license Google Mobile Services.
Until Google alters the deal.
> Also, that isnt even a security issue. Its a freedom issue.
There is no security without freedom. If you're protected by a steel door, but you don't have the key, you aren't safe: You're imprisoned. You can't protect yourself from Google without having freedom to run what you want on "your" device.
Im not trolling. You say you dont trust Google at all. Thats your position. Then my argument is to not trust their code, regardless of which project its submitted to. How is that unreasonable. Your argument is the unreasonable one. You somehow think contributions by other companies to Linux would balance out or erase your trust issues with the Google code? Why would that make any difference.
> This is not the actual issue. The actual issue is that existing patches for a known vulnerability become unavailable, because Google decided so, making GOS potentially insecure. Patches without the source code shouldn't be trusted.
The issue gets patched. Whether the code is published doesnt change the code... People can also sti reverse engineer the code. Its not a black box. Its often just Java code. You can easily decompile Java, bytecode maps easily to the source code. Its an effort you have to do, yes, but so is reading and properly auditing the source code as well. You seem to think publishing the code somehow magically makes it more secure. While that isnt true. People would still need to properly audit it. It barely happens in practice. And it can also perfectly be done with compiled code.
> Until Google alters the deal
If Google were to put the restriction in AOSP, GOS can simply remove it from the code... And if its not in AOSP than it doesnt impact GOS.
> There is no security without freedom. If you're protected by a steel door, but you don't have the key, you aren't safe: You're imprisoned. You can't protect yourself from Google without having freedom to run what you want on "your" device.
This metaphor doenst make any sense in relation to the planned sideloading restrictions. I suggest reading the blogposts from Google about what the process will look like.
The thing you link about restricting network traffic doesnt make much sense. GrapheneOS has a proper network permission which other OSes dont have. The outbound traffic restrictions to certain destinations which are being referred to are just a bad approach. You can send the traffic to one server and just process it there and send out to other servers.
You also say :
> Also, if I explicitly don't trust Google with anything, GOS is extraordinarily insecure for me until a new vendor
If thats the case, dont opt for GNU/Linux either given the large code contributions made by Google. Also avoid any software built with LLVM, written in Go, written in Flutter, using Angular, ...
The two "problems" you link arent really huge security issues. How is GrapheneOS having access to the embargoed patches and being able to ship them a security issue? Also the planned sideloading restrictions dont even apply to GrapheneOS. It would only apply to certified OS that license Google Mobile Services. Also, that isnt even a security issue. Its a freedom issue.