I think we’re broadly in agreement here, and I think both our statements are important to the Linux discussion. Moreover, we’re not speaking privately - I wish I could direct recent converts from Windows to this thread as a whole, as you offer good advice - be wary of your sources & learning how to inspect gifts you’re offered is excellent advice.

This is absolutely a shortcoming of Arch - but I don’t see it getting fixed soon. Your change is practical, and could reduce the attack surface for bad actors, but it also introduces gatekeeping and would slow down time from code change to deployment. The open community and blazing fast end-to-end turnaround are both Arch key features (in my opinion).

If you prefer more vetted code, there’s other great distros (Debian leaps to mind).

But honestly - yes, some people got hurt - but it was addressed in a day. That’s not a bad turnaround ~ I’ve certainly seen that damage wrought by Windows- and iOS-based malware run at least that long.

This can be seen as the system working as intended. Please don’t run Arch on mission critical systems. There’s other distros for that. While this vulnerability is Arch-specific, this OS is often a canary for others. But if you can tolerate being on the frontier, Arch is very well documented and is great for learning - and yes it has some risk.

For you and me, that’s fine, but for little johnny first time, it’s adding friction and new points of failure that push the whole idea further away from their comfort zone.

It could be argued that Microsoft knows this and is deliberately weaponizing peoples insecurities to keep them in line.

Also, “Been available since 2023” means Microsoft gave distros 2-3 years to implement the new signing keys. Yet they’ll give themselves decades between signing and updating their own root certificates.

Example: on my work machine, “Microsoft RSA Root Certificate Authority 2017” is valid from 2019 to 2042. It’s valid for 25 years, but it took Microsoft 2 whole years to deploy the certificate within it’s own structure, specifically to get all the relevant sign-offs needed to issue the cert.

Not really. Browsers were one of the first pieces of software to do sandboxing, but now virtually everything uses sandboxing for organization and security - Android apps have a permissions manifest so they can be sandboxed. Amazon cloud servers are mostly Kubernetes clusters, which is just sandboxed virtual machines. ChromeOS already is a OS/browser hybrid with native sandboxing (and the short lived Firefox OS. Running a 32 bit app in a 64 bit environment requires a compatibility layer, which is a sandbox. If browser technology has already been pushed through the OS stack, why not complete the loop.

The main use case for hardware acceleration is progressive web apps, which is literally a plan as old as 2006 to make browsers able to securely run signed code natively (as an alternative to using extensions like ActiveX, Java, Shockwave, etc, all of which were notoriously insecure).

So honestly, I don’t think it’s a dumb idea at all. It would honestly be kinda cool if I could go to blizzard.com and just launch a game full screen, securely with a simple approval rather than downloading and running a separate launcher app. (Assuming the implementation was otherwise sane; I know the current environment of enshittification could torpedo the idea entirely)

Unless they track Steam Deck specific fingerprints the OS may be classified as Arch, but either way: yes, every Steam Deck counts as a Linux system out of the box.