> 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.
What hollerith said.
> Nobody uses npm on a GNU/Linux phone. As the OP correctly mentioned, the whole security model relies on the trusted apps. See also: https://source.puri.sm/Librem5/docs/community-wiki/-/wikis/F...
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):
https://github.com/dagimg-dot/vicinae-gnome-extension
https://github.com/vicinaehq/vicinae
But there are others like this one:
https://extensions.gnome.org/extension/4839/clipboard-histor...
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).
—
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1565196
[2] https://developer.arm.com/community/arm-community-blogs/b/op...
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1671152
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1626955