202
New US Congress bill proposal requires all operating system providers to verify ages
(www.gamingonlinux.com)
this post was submitted on 15 Apr 2026
202 points (99.0% liked)
Gaming
4746 readers
156 users here now
The Lemmy.zip Gaming Community
For news, discussions and memes!
Community Rules
This community follows the Lemmy.zip Instance rules, with the inclusion of the following rule:
- No NSFW content
You can see Lemmy.zip's rules by going to our Code of Conduct.
What to Expect in Our Code of Conduct:
- Respectful Communication: We strive for positive, constructive dialogue and encourage all members to engage with one another in a courteous and understanding manner.
- Inclusivity: Embracing diversity is at the core of our community. We welcome members from all walks of life and expect interactions to be conducted without discrimination.
- Privacy: Your privacy is paramount. Please respect the privacy of others just as you expect yours to be treated. Personal information should never be shared without consent.
- Integrity: We believe in the integrity of speech and action. As such, honesty is expected, and deceptive practices are strictly prohibited.
- Collaboration: Whether you're here to learn, teach, or simply engage in discussion, collaboration is key. Support your fellow members and contribute positively to shared learning and growth.
If you enjoy reading legal stuff, you can check it all out at legal.lemmy.zip.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
What happens if secure boot is enabled privacy wise?
Secure boot by itself isn’t a bad thing. It basically just says the OS you boot from has to have a signed and approved bootloader/drivers. The problem is, the approval list is handled by the board manufacturer and not every version of Linux supports it since it has to be signed and approved. Also, if you have unsigned kernel level modules (such as an open source video driver) that can cause the process the break as the driver isn’t signed. I believe user space is much more accepting.
From a privacy aspect, it isn’t directly impacting, except it limits which distros you use, and may prevent you from doing other privacy related changes as a low level or forcing you to use signed binaries that you may not be able to audit.
Edit: a few notes as I went diving further. So Microsoft actually controls the root CA that SecureBoot is based on and signs other apps, including Linux and then they add their own shims in. So sadly MS still has control out of the box.
However, it is possible on most (not all) systems to add in your own signing keys to the secureboot enclave. So with enough work you can do it yourself, but you basically have to make sure everything is signed with your key when you compile the kernel and associated drivers.
Oh I see, so it is basically a corporate controlled allow list that could be used for forcing you to have a specific system. Absolutely disgusting that this is hidden under the guise of security
That’s…. a stretch. The issue is that the default CA that manufacturers include is Microsoft, so Debian developed a shim, signed by Microsoft, so that they could sign their own distros ans modules.
Since a lot of boards allow you to inject your own key into the MOK for UEFI, you can basically roll your own with a little work. It’s just not “out of the box” since they’d have to validate multiple different distros.
It’s more a matter of sheer size of Microsoft vs Linux rather than locking. I’ve said “a lot” and “most” around boards given that I’m not sure what the breakdown is, but I haven’t seen a board that doesn’t do that.