Ironically this is a security focused thread. The solution here isn’t to switch to a Linux phone, a platform that has absolutely atrocious security, especially compared to even stock iOS/Android. The only alternative that actually increases privacy and security is GrapheneOS. If one doesn’t want to buy a Pixel in order to have it, they can wait and see what the new OEM that will support GOS will be later this year before deciding if it’s worth waiting for in 2027.
Like what the person you replied to said. Sandboxing on Linux phones is incredibly weak outside of non-Flatpak Chromium browsers. And even Flatpak itself is a pretty weak sandbox compared to iOS/Android sandboxing. Part of this stems from Android and iOS being developed as sandbox-first OSes, so this could be said for any desktop operating system really aside from ChromeOS.
Also sure you could avoid crapware from Meta, Google and the likes but you will still could be exposed to nefarious programs via things like supply chain attacks (i.e. npm), or the developer turning coat or not realizing their app has an exploit, etc.
Linux also lacks a thorough permissions system unlike iOS/Android and the even more granular GrapheneOS.
Linux phones lack verified boot meaning persistent malware is trivial on linux devices. There is no MTE/MIE on Linux phones and even Google themselves say like 70% of malware spawns from memory exploits[1].
Also linux only really has block level encryption, not file based encryption like iOS/Android. It would be trivial for LEO to access your device unless it was totally powered off and then the only protection is LUKS. Or really even if you lose your phone and someone was so inclined to they could just extract all the data if it was powered on but on the “lock screen,” as most if not all desktop (and I’d imagine linux phone) environments do not actually do any encryption or anything when the system is locked, it’s just a cosmetic lock for all intents and purposes.
It would maybe be possible to somewhat mitigate that with cryptomator or somehow using fscrypt since that’s what Android uses but I dont know
Also even for basic things like clipboard protection, even with Wayland there are ways around it so that an app can read anything from the clipboard (not usually done for nefarious means in my experience, but it’s possible — see an app like Vicinae’s clipboard history and clipboard-centric features running on Wayland).
There’s more but this is like a short overview.
This doesn’t even get into people preferring Firefox on Linux which is light years behind Chromium based browsers in terms of security.
While it’s not a huge issue on desktop depending on how you view it, I would imagine phones see way more of people’s private data than their computers do and so I think it’s more beneficial to have higher security here than give that up for Linux.
> Linux phones lack verified boot meaning persistent malware is trivial on linux devices.
Librem 5 has a 3FF Smart card reader. Also, it can be completely wiped and reinstalled, ensuring that your phone is cleaned whenever you suspect a compromise.
> Or really even if you lose your phone and someone was so inclined to they could just extract all the data if it was powered on but on the “lock screen,” as most if not all desktop
I never heard about such possibility. Could you provide some details or links on how this could be done? AI says it's not really possible without very sophisticated instruments.
> It would maybe be possible to somewhat mitigate that with cryptomator or somehow using fscrypt since that’s what Android uses but I dont know
Indeed, GNU/Linux phones can and probably will improve their security with time taking some things from Android.
> Also even for basic things like clipboard protection, even with Wayland there are ways around it so that an app can read anything from the clipboard
You can't just say this without any evidence.
> This doesn’t even get into people preferring Firefox on Linux which is light years behind Chromium based browsers in terms of security.
Unless you switch off JavaScript, which is what I do.
>it can be completely wiped and reinstalled, ensuring that your phone is cleaned whenever you suspect a compromise.
A modern computer or smartphone contains many peripheral CPUs. E.g., the hardware that implements USB probably has one. Each of these peripheral CPUs runs its own software or firmware. "Completely wiping and reinstalling" only works
if the compromise did not get into any firmware of any peripheral or did get in, but for some (miraculous) reason cannot reinfect software running on the main CPU.
There is a reason we used to hear constantly the advice to reinstall Windows, but no longer hear it: the old advice no longer works reliably.
So, not only is wiping and reinstalling more laborious and time-consuming than just rebooting a system with a verified boot chain, it is not as reliable at ridding the system of an infection.
> Librem 5 has a 3FF Smart card reader. Also, it can be completely wiped and reinstalled, ensuring that your phone is cleaned whenever you suspect a compromise.
npm was just an example of how open source projects can be infiltrated. “Trusted” apps
> I never heard about such possibility. Could you provide some details or links on how this could be done? AI says it's not really possible without very sophisticated instruments.
There’s nothing special here. Linux phones/desktops (including Purism in theory in the future, as it doesn’t have by default FDE yet according to that FAQ if it’s current), typically only utilize Full Disk Encryption via LUKS. Which is also the direction Purism sounds like they’re going as they have no mention of fscrypt or something like systemd-homed and you only enter a decryption PIN on boot (like is currently done with their laptops).
So with LUKS it only encrypts at the block level so the drive is fully unencrypted when it’s mounted and unlocked. A display manager’s lock screen only “locks” the device visually, it doesn’t / can’t re-lock the volume since it operates above LUKS. So if someone were to take your device while it was powered on in theory they could just extract everything without issue (although I’m not sure of what USB protections Purism has — there are things like USBGuard for linux, but that could be easily defeatable, I don’t know).
It’s why I mentioned something like systemd-homed because it provides a way for user directories to be re-encrypted on logout/lock and prevent this. fscrypt also can do this and is part of why LEO can fail to extract user data in AFU on android devices.
Sorry I kind of just dumped this all out I can elaborate more if needed.
> Indeed, GNU/Linux phones can and probably will improve their security with time taking some things from Android.
Ultimately this is my main problem with Linux phones. Eventually you come back to just re-inventing Android, maybe worse because you didn’t have the resources to speed run all of it’s security improvements, so who knows how long it’ll take Linux to catch up. I don’t know if I’m missing something but why not just fork AOSP, migrate it to a newer Linux kernel (since iirc AOSP is based on like a 4.xx linux kernel), and go from there? You’d have all the power management, security features etc and be detached from Google.
> You can't just say this without any evidence.
Maybe I overspoke here. More specifically a GNOME extension can definitely read from the clipboard/selections without a user knowing, like this one for example, which I used on my system running secureblue (which disabled xwayland by default):
Now these probably aren’t malicious, but I would now wonder if a “good” extension can turn coat and start doing that. Of course GNOME extensions really aren’t ideal and if you’re on KDE or something else it probably doesn’t affect you.
> Unless you switch off JavaScript, which is what I do.
There are still significantly more security benefits than just disabling JavaScript though (which imo is not realistic for most users just due to how the web is today, really we should just be able to disable V8 and use Drumbrake instead).
For example, Firefox on Android still lacks site isolated processes[1]. It also has no JIT sandbox or content sandbox and no type-based CFI. And unlike Chromium it seems like the Mozilla team doesn’t really have an interest in keeping up with ARMs latest security features and using them, such as Branch Target Identification and Pointer Authentication which Chromium takes advantage of[2]. Firefox has no progress on either of these[3][4].
Firefox also lacks a security-focused memory allocator, and cannot handle one (try using GrapheneOS’ hardened memory allocator (hardened_malloc) with any Mozilla apps on Linux or GOS).
> Every software can be infiltrated that way, it's actually harder with open source.
I mean yes. I guess in theory it’s harder with open source but that’s something that’s hard to track with statistics I’d imagine. Well, intentionally placed backdoors at least are for sure are way more likely to be discovered in open source than closed source.
> But we were talking about regular GNU/Linux here, not android, right?
Firefox on GNU/Linux is the weakest form of the browser security wise by far, even as a flatpak, as Mozilla treats it like the lowest priority platform despite being the browser of choice by the average Linux user. Firefox on Windows and macOS has security features that are barely in the brainstorming stage on Linux (due to a multitude a factors, some probably not the fault of Mozilla).
On Android it’s still worse in security than Chrome/Vanadium/Brave.
I think that's because they don't consider the apps in their app store to be malware despite doing things like starting a server on localhost to circumvent sandbox.
