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.
> You made a general statement about attacks from GOS on GNU/Linux.
No, I provided two specific examples, one quoted and another linked to. None of them happend in the context of wrong comparisons being made.
> 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 completely unreasonable. Google has full control over Android and therefore GrapheneOS. It has very little control over Linux. All their contributions to Linux are carefully verified by many independent
parties and suspicious things not accepted by community are rejected. The latter doesn't happen in Android, see my examples above.
> The issue gets patched. Whether the code is published doesnt change the code...
Only if you 100% trust Google. I see you do and promote them. I wonder why you would defend a trillion-dollar, monoppolistic megacorp hostile to its users.
> People can also sti reverse engineer the code.
This takes huge effort and time. One can't rely on it to be secure.
> If Google were to put the restriction in AOSP, GOS can simply remove it from the code...
The effort to keep a hard Android fork up-to-date will grow exponentially. I don't expect that GOS team will manage to do it for long.
> This metaphor doenst make any sense in relation to the planned sideloading restrictions.
This is exactly what is happening with Android right now. Users are constantly loosing their control over the device in the name of the false sense of security.
> I suggest reading the blogposts from Google about what the process will look like.
This is not even funny. Are you working at Google? I suggest you to read blog posts by a non-profit instead: https://eff.org.
> No, I provided two specific examples, one quoted and another linked to. None of them happend in the context of wrong comparisons being made.
You made a general statement here ("being known for"). You put a link there indeed with a quoted example and another link.
> Indeed the GrapheneOS community is known for attacking the GNU/Linux mobile with false claims, https://news.ycombinator.com/item?id=45562484.
You have to look at the parent replies of what you link. Read the thead properly, please. Like I said , "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". Replies that were literally mentioning GrapheneOS got a reaction. Thats not an unfounded attack. The statements that those other options are less secure are clearly backed up with technical information.
> All their contributions to Linux are carefully verified by many independent parties and suspicious things not accepted by community are rejected. The latter doesn't happen in Android, see my examples above.
That's really not how it works in practice. There is a ridiculius amoumt of code and code changes. Systematic proper exhaustive auditing doesnt happen. Also, you distrust Google and think they are malicious. Google can do their best to hide bad stuff in their code so quick reviews wont notice it. Do you think malware developers write functions called doTheBadStuff()?
> I see you do and promote them. I wonder why you would defend a trillion-dollar, monoppolistic megacorp hostile to its users.
I am not promoting Google. I am just countering your posts critizing Google using bad arguments. Google is a multi-faceted compamy some of the things they do are good for end users, some aren't, most things will be liked by some and disliked by others.
> This takes huge effort and time. One can't rely on it to be secure.
Reading and properly understanding source code also takes huge effort and time. And like I said, if you dont trust the devs, you cant trust function names, variables names and code comments to give a faithful portrayal of functionality anyway. So do you really lose that much if you decompile Java bytecode and mainly just miss naming and comments? It can even be argued it will remove preconceptions and let you read the code with a more open mind. Its a hurdle and annoying for sure, though. I would prefer Google to lower the embargo as well. But, public source availability just isnt the magic silver bullet you think it is.
> The effort to keep a hard Android fork up-to-date will grow exponentially. I don't expect that GOS team will manage to do it for long.
You dont need a hard fork for that. If the sideload restriction were to be put in AOSP you can remove that in a soft fork.
> This is exactly what is happening with Android right now. Users are constantly loosing their control over the device in the name of the false sense of security.
I agree Googles plans arent a good approach. But it isnt a false sense of security either. Registering app IDs and associated public keys is a usefil thing. There are other, begger approaches though, tbat dont have the downsides of what they planned.
> This is not even funny. Are you working at Google? I suggest you to read blog posts by a non-profit instead: https://eff.org.
Based on what you were saying and your bad metaphor it is just clear you arent accurately informed or up to date about what the sideloading restrictions will be. The best place to read what the procedures will be is in Google's blog posts and documentation. I am not saying you have to go read that to make a value judgement on the merits. You just need to read that to understand what is actually being talked about. I dont like Google's plans either but I am aware of what they are.
Something being a non-profit doenst automatically mean all posts they write are of good quality. EFF does many good things but I dont see why their posts about things are somehow automatically good and authoritative because of their non-profit model. Best to judge individual posts on their merit.
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.