Correct me if I'm wrong, but the way FDE is implemented in Librem 5 means that it is only effective when the phone is turned off? The disk is decrypted when you type in your LUKS passphrase and after that, it stays decrypted until you completely power it off or reboot. That makes it pretty much useless on a phone that you carry around.
The linked source has a lot of stuff that is done "in the future" and basically all of those "in the future" suggestions, are inferior to what AOSP has had for years.
The document lists some of the drawbacks of Librem 5, such as the use of memory-unsafe languages, and then blames Android for also relying on the same memory-unsafe languages and even some Android-specific components written in memory-unsafe languages. The fact is that Android has tons of mitigations specifically for this problem, which Librem 5 completely lacks. They're not comparable in that way. Librem 5 basically exposes the entire Linux kernel attack surface, whereas Android has multiple layers of protection between userspace and the Linux kernel. Apps written in memory safe language, proper app sandboxes, hardened memory allocator, extremely strict SELinux policies, CFI, PAC, ShadowCallStack, etc.
The only nice thing Librem 5 has, are the killswitches, but do those really matter at this point?
Yes, desktop GNU/Linux has a long way to go to get to the security model of Android. Yes, FDE only works for the turned off device (at the current stage). But, depending on your threat model, the phone can already be more secure nevertheless.
For example, if you do not trust the manufacturers in China, you can verify the schematics, or order Librem 5 USA. Or, if you suspect your device is compromised, you can rely on the kill switches to make sure you are not tracked or listened to. Can you do these on Android? I'm sure there are known vulnerabilities for the latter on the black market.
Another example: If you use the smart card to read or sign your emails, you can be sure that even a hacked or stolen unlocked phone would not allow the attackers to manage your email identity.
People who say that Librem 5 is less secure than Android do not take into consideration that threat models can affect it a lot. You cannot simply declare "it's insecure" without considering the threat models. Also, I guess if you are fine with the security of your GNU/Linux laptop, which you take with you, you should be also more or less fine with the Librem 5 security.
I am not even speaking about the freedom benefits. Also, there is no security and privacy without freedom (https://puri.sm/posts/why-freedom-is-essential-to-security-a...). In the long term, Google is heading toward the walled garden on Android, just like Apple does. I would not bet on it for the future. If you care about security more than freedom and need Android-style security now, then Librem 5 is not for you.
The linked source has a lot of stuff that is done "in the future" and basically all of those "in the future" suggestions, are inferior to what AOSP has had for years.
The document lists some of the drawbacks of Librem 5, such as the use of memory-unsafe languages, and then blames Android for also relying on the same memory-unsafe languages and even some Android-specific components written in memory-unsafe languages. The fact is that Android has tons of mitigations specifically for this problem, which Librem 5 completely lacks. They're not comparable in that way. Librem 5 basically exposes the entire Linux kernel attack surface, whereas Android has multiple layers of protection between userspace and the Linux kernel. Apps written in memory safe language, proper app sandboxes, hardened memory allocator, extremely strict SELinux policies, CFI, PAC, ShadowCallStack, etc.
The only nice thing Librem 5 has, are the killswitches, but do those really matter at this point?