> [..] It's basically just a Desktop computer in the form-factor of a phone.

Which is what has me worried the most.

The (common) security model of GNU/Linux is for today/2020 in my opinion pretty bad for desktops and totally unacceptable for phones.

When I first heard about snap and flatpack I thought things are slowly heading in a better direction but it turns out that was a misconception.

I haven't looked into how the libre phone does sandboxing but I don't have to much hopes to be honest.

> The (common) security model of GNU/Linux is for today/2020 in my opinion pretty bad for desktops and totally unacceptable for phones.

Would you please expand on this for desktops? or reference any kind of document? Thank you.

Mostly what Zak says.

All applications and (preferable system services too) should be sandbox fist. Linux has much sandbox technology but it's often focused on server use-cases, fairly complex and everything but sandbox first (more like non-sandbox first and then we fit the sandbox to make it so that the program doesn't notice it runs in one).

But it's also many many small problems.

Most (all?) of which you can solve by a complex combination of selinux + cgroups + ... + modified applications + ... (long list). But doing so it a lot of work and often ends up with major usability drawbacks.

Just to name one example of a small but terrible feature: LD_PRELOAD.

Sure it's nice for hot-fixes including ad-hoc security hardening but it's generally a horrible idea in a context where you don't fully trust all programs.

Another think is that most programs can read conigs/settings of most other programs or at least know that there are such settings.

And the list goes one.

Again just to be clear you can fix a lot of this by putting things into Linux containers but what is missing is a container engine focused on desktop applications which goes far enough, which also entails you can't just run existing software without at least switching out the GTK/Qt framework with a version adapted for this use-case and potentially needing more adaption then this.

So all technical possible but we are not quite there yet I think, but then I'm not completely sure as I haven't followed some of the underlying topics close enough in the recent years.

I'm not the one you asked, but I think the underlying issue is that the Unix security model is built around the assumption that software shares the user's intent, and is treated as exactly as trusted as the user. Computers at the time tended to be multi-user, so the focus was on protecting users from other users. While there was a risk of overtly malicious software, preventing remote code execution attacks and teaching users not to run trojan horses was mostly sufficient (for Unix users; the broader population using Windows often installed malicious adware in the early 2000s).

In a modern environment, software should not necessarily be trusted to act in accordance with the user's wishes or best interests, and there's often a financial incentive for software creators to do things users wouldn't want them to. In the early 2000s, the most visible issue was Windows software that displayed advertisements outside of the software, often not obviously connected to the software. It would often monitor the user's browsing habits and such, leading to the name "spyware".

Spyware of that sort was universally considered malicious, but modern smartphone apps often send far more sensitive information, such as location and address books to their creators. Those provide a simple example of a situation the classic Unix security model doesn't address very well. I am the only user of my phone, and I obviously want to be able to read my address book and get my location from the GPS. I do not want the latest and greatest app for sharing pictures of my lunch to track my location to show me restaurant ads, and I only want it to know about people I have explicitly connected to within the app, not my whole address book.

Android's security model addresses that to a degree, restricting some capabilities until the user explicitly allows them. Some of these, like filesystem access aren't handled very gracefully, and it's possible for an app to refuse to work until granted permissions it doesn't really need (this is against policy for inclusion in the Play store, but enforcement is imperfect, and software can be installed from other sources). One workaround seen in XPrivacy is to feed fake data to apps.

AFAIK XPrivacy needs root to be installed, which would break part of the android security model.

Not just root, but Xposed, which breaks the Android security model even more.

Breakage isn't binary though. The user is still in charge of whether a given app gets access to root or Xposed features. The Android security model and additional security features of XPrivacy can be applied to apps the user does not trust with certain kinds of data or capabilities while granting other apps increased access.

>> Add tools that let me see what my phone is doing behind the scenes.

>Everything is open source. You have all the power to study what your phone is doing. Standard GNU/Linux tools should work.

Yes, for the base system, however for third-party stuff, it would still be nice to prevent the apps from phoning home and stuff.

But how do you already do it on GNU/Linux? You can do the same.

Of course you can, but is it obvious and user friendly?

Linux phones are never going to be especially obvious or user friendly. To get those types of features you need a boatload of investment that the open source community can't hope to muster in any sort of reasonable timeframe.

For now the choice is privacy vs user friendliness. Currently rooted/de-Googled Android provides one of the best compromises for the average privacy-minded power user, but maybe in a few more years these Linux phones will be mature enough to give Android more of a run for their money.

> To get those types of features you need a boatload of investment that the open source community can't hope to muster in any sort of reasonable timeframe.

The Linux desktop is an obvious counterexample. If the open source community can develop user-friendly desktop environments (GNOME, KDE Plasma, Xfce) they can surely develop user-friendly mobile stacks.

> Everything is open source. You have all the power to study what your phone is doing. Standard GNU/Linux tools should work.

The vastness of the just the changelogs makes that untenable. Understanding the changes to such a nontrivial stack is something experts will even struggle with.

Certainly, open source code is a prerequisite to any trust, but just that isn't enough.

Everyone needs to check just one small thing of their choice. It would be enough for a good coverage.