by armadyl | 2026-02-13 17:05:13+00:00
> 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.

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