Is it wrong to call out those complying in advance with fascism? I will agitate in any way that sparks debate and encourages people to be more aware of what is at stake. I gain absolutely nothing else, especially on Lemmy… maybe if this was Reddit you could accuse me of being some shill farming karma. But that shit culture doesn’t exist here.
This is an argument of principle, if I’m understanding it correctly. GrapheneOS wants as many opportunities to get on devices that meet their criteria as possible, and mandating this alternative attestation be part of the OS might prevent GrapheneOS from ever being compatible with these devices unless the GrapheneOS devs implement it. The devs do not want and/or agree with it in its current form, for the reasons they laid out.
That being said, GrapheneOS already does implement the hardware attestation they talk about, and in fact I am using it right now via the remote attestation setup with GrapheneOS’s attestation server.
Yes, the PR specifically calls out the laws as the reason for this change. The problem is BOTH the laws getting passed, and corporate interests complying in advance.
Through this conversation I learned SixOS (systemd-less NixOS) exists
If the whole story was the addition of this change with no other context, I’d agree. But if you read the PR description you’ll see its more than that. The laws in question are specifically called out. This suggests that whether or not the legal interpretation of compliance changes (the law could require more than just DOB entry, aka DOB verification with government ID), systemd is planning to comply rather than join the legal battle against these invasive requirements.
Gonna be real with you, I’m not running a password checker tool over unencrypted http. Is this vibe coded?
Seems like a horrible eagerness to comply in advance with equally horrible US state laws when this legal scenario is not even close to resolved.
Exactly. This is a massive overreach, and it is crazy that Poettering is even considering merging this.
Brother. You tried to run a repack that was likely developed and tested on Windows, and then got pissed when it didn’t work. This is Linux, you downloaded it for free… there is no megacorp surveilling your system and trying to fix every single gaming edge case so that you stay happy while they shove ads in your face.
If you just want gaming and want to stick your head in the sand and stay completely unaware of how your OS works and what it is doing, absolutely stay on Windows. If you have the slightest care about your privacy, desire to learn about how a computer OS works, or are curious about free software, then join us… there are tons of people out there willing to help you.
And I’m sure there is a way to get that repack working… it may just take some research and actually asking questions in the community.
For as long as major powers control the production of the majority of computing devices this will be true. But as far as I know there are no short term alternatives for completely open mobile device hardware… so if hardware backdoors are in your threat model then unfortunately mobile devices are not for you…better stick to the very small community of open hardware for laptop/desktop computers for your communication needs.
Of course, no question that with threat modeling you can arrive at /e/OS being an acceptable choice. However threat modeling is difficult and the devil is in the details, which is why I’m responding (mostly for the benefit of other readers of this thread) to provide the GrapheneOS side of things and avoid the impression that /e/OS offers unique or generally superior features in the areas we are discussing.
Here is GrapheneOS’s network location implementation details. https://grapheneos.org/features#network-location
From the official GrapheneOS response to exactly this same debate, it seems that the issue is MicroG’s reliance on having signature spoofing enabled. Which is a security hole that can be exploited by anyone, not just MicroG, as it allows anything to masquerade as Google Play Services to an app that wants to use it.
https://discuss.grapheneos.org/d/4290-sandboxed-microg/11
Yes, Google Play Services is closed source and contains functionality that would be considered “spying on the user”, and “malicious”. But that is the same for any closed source app; you can’t prove it isn’t trying to spy on you or compromise your device. What you can do is rely on the App sandboxing and fine grained permissions control that GrapheneOS allows to disable such functionality if it exists.
Of course, if even having a closed source app on your device is too much, then honestly you wouldn’t even be using MicroG as you wouldn’t want any apps using Google’s proprietary libraries for accessing Firebase or other proprietary services anyways…
So, GrapheneOS offers the most sane approach in my opinion, without opening any security holes. By default the entire OS (not talking about pixel firmware blobs, just the os and kernel drivers) are open source and you can use only open source Apps via Fdroid, Accrescent, direct with Obtainium, etc. But for the average user enabling sandboxed Google play and managing its permissions is the best compromise between security and privacy.
Spent 4 hours on Sunday debugging “SW microcode error” iwlwifi crashes… eventually found some random shit on the Arch forums where you turn a bunch of shit off and it fixes it
Bravo Michael for continuing to farm bullshit drama with clickbait headlines on the most inane topics like “how my DE handles pasting text”
Graphene isn’t a ROM, it is a standalone mobile OS based on the Android Open Source Project. So yes, Google primarily develops it, and has de-facto control. But Graphene is actively working to change that, especially with partnering with OEMs so that they can increase device driver support and give more devs incentive to work on AOSP/Graphene in general. For mobile devices the device drivers are huge, unlike desktop/server linux where MOST (obviously not all) things work.