Once KDE 6.8 is released, Valve must add Wayland support for Steam client and Proton/Wine. Also, they should drop 32-bit dependencies for Steam client on Linux, which has been done for Windows and macOS long ago.
+1. Most games, once shipped, completely disband their development team.
If you require game developers to even so much as recompile their game, they simply cannot do it. If you want the game to keep working, you have to guarantee ABI compatibility in perpetuity.
I'm in favor of removing 32-bit dependencies from steam-the-application, except that you still need 32-bit libraries to run 32-bit games in Wine.
Having steam depend on those libraries directly means that when you install you get all the libraries you'll need and you won't run into issues later on when you go to run a 32-bit game and it can't load the appropriate 32-bit system libraries for you. It's annoying for sure but it simplifies the user experience dramatically (especially if you're just installing Steam directly on Ubuntu or something).
Porting traditional Linux desktop distributions to Android devices is meaningless, all you get is more instability, more unsafe and more trouble. Waydroid is a bad implementation on security and compatibility, just running Android in VM is better.
Waydroid disables most of the Android privacy and security model through not having functional SELinux. SELinux is not simply an additional layer of security on Android but rather deeply integrated into the OS. The app sandbox and isolation throughout the OS are heavily built on SELinux. It also heavily depends on it for kernel attack surface reduction combined with internal kernel hardening via exploit protections.
Waydroid uses an outdated fork of LineageOS running with namespaces and a compatibility layer on top of a much less private and secure base OS without similar kernel or userspace security protections. Running up-to-date AOSP in a virtual machine would at least be able to preserve the internal Android privacy and security model for apps to protect apps from each other and the OS from apps. It would also contain the overall OS within it too. Using the much less private and secure OS as the host OS with full access is quite backwards from a privacy and security perspective but would be a huge improvement.
AOSP is much more private and secure than traditional desktop Linux distributions. Moving to that software stack is inherently going to be moving much further away from competing with the privacy and security of iOS. The direction taken by GrapheneOS is to start from AOSP and greatly improve the privacy and security it provides to compete with and exceed the industry standard privacy and security provided by iPhones. That requires more than only software. Hardware and firmware security are very important too. Software security also increasingly depends on hardware-based security features such as hardware memory tagging, hardware control flow integrity protections, hardware-based virtualization and much more.
Keeping user data safe from access via encryption also depends on hardware security features for the vast majority of users not using a very strong passphrase. People take it for granted that they're going to have secure data via disk encryption with a random 6 digit PIN but that's not the case without a good secure element and OS integration with it. The approach used by desktop operating systems with TPMs is awful and makes security worse in a lot of ways rather than better. It's not at all the same thing, similarly to how what the desktop world calls secure boot is not a serious or complete implementation of it and doesn't provide nearly any useful security properties to end users unlike iOS or AOSP.
This is a meta comment, but I just wanted to thank you for your engagement and insight that you've shared throughout these threads. I personally get a ton of value out of it and really appreciate it!
> The approach used by desktop operating systems with TPMs is awful and makes security worse in a lot of ways rather than better. It's not at all the same thing, similarly to how what the desktop world calls secure boot is not a serious or complete implementation of it and doesn't provide nearly any useful security properties to end users unlike iOS or AOSP.
Interesting. Could you elaborate? I always thought that Secure Boot is reasonably secure (provided you can set it up in the first place).
The standard UEFI Secure Boot used with traditional Windows and traditional desktop Linux is an incomplete and insecure implementation of secure boot. It doesn't verify the vast majority of the OS, nearly always lacks an unbroken chain of trust from the hardware, does not verify all of the firmware and lacks downgrade protection for both most of the firmware and the OS. In the typical setup, it trusts an enormous number of keys and software. It barely provides any useful security properties.
Secure boot was widely used as a term prior to the UEFI usage of the term including many much more meaningful implementations. The term verified boot refers to the same concept but avoids it being confused with solely verifying a late stage bootloader and OS kernel from UEFI firmware.
Ah yes, so if I understand correctly, you're referring to the fact that, e.g., on Linux a typical Secure Boot setup will verify the kernel (if at all) but not the rootfs. Yes, that's of course a huge issue (as is mutability of the rootfs in the first place). I think what I had in mind is indeed more akin to the "verified boot" setup you described.
Our duress PIN/password feature doesn't pretend that it can stealthily wipe the device. It properly implements what people expect it to do and does it safely. It isn't our role to choose how to use the feature including how to use it in a situation where there are potential consequences to it. We haven't implemented any features which are in any way specific to situations involving law enforcement. We aren't going to give people any legal advice on how to handle situations involving law enforcement. It isn't our role and does not make sense particularly since laws vary so much based on jurisdiction, context and how they're interpreted on a case-by-case basis. If people want legal advice, they should ask a lawyer for it.
It's not possible to provide anything close to plausible deniability for wiping profiles. A deleted profile leaves behind metadata proving it existed in the device encrypted and Owner profile encrypted storage. There are a whole bunch of different ways it can be shown that it existed. ADB can be easily used to identify a wipe occurred and when it occurred. The standard approach used by forensic tools is connecting via ADB and they can easily add support for detecting this. It would be easy for non-experts to figure out how to do it especially with the guidance of a decent LLM. It would put users at risk who believe they can perform a stealthy wipe despite it not being possible. We do not want to provide a feature which cannot come close to working properly.
Android's Private Space has a half-baked feature for hiding that the Private Space is enabled in the user interface for someone without access to the relevant unlock methods or ADB. There are multiple publicly known ways to identify a Private Space is enabled. These aren't treated as significant security vulnerabilities and fixes for it aren't backported to older releases. It isn't practical to cover all possible ways of detecting it even with the limited scope of only attempting to hide it in the user interface and not ADB. We don't plan to remove the feature but don't think it should have been implemented and wouldn't have done it ourselves.
If we implemented a half-baked deniable wiping feature then the flaws would be discussed in this forum, our issue tracker and elsewhere on the internet. It would quickly become known to LLM models, which would be able to assist with detecting it. It would be incorporated into standard forensic tools and guides. This is not an approach we want to take with GrapheneOS.
Our features need to work against adversaries aware those features exist. An adversary aware of the duress PIN/password existing doesn't have a way to tell it apart from a real PIN/password. They'll have to consider if a PIN/password provided to them could be a duress PIN/password even for users who don't use the feature. The feature is now going to be widely known about due to the news coverage and it's still going to work.
On future devices, we want to add duress PIN/password support to the secure element as part of the Weaver rate limiting so it can't even be bypassed with an OS exploit.
reply