If you don’t mind I am curious to hear your reasons. I personally agree with the developer, I think it’s a lot of work and doesn’t provide a meaningful win. If an attacker has access to the system, there are many other ways they can access your notes even if the notes are encrypted at rest. Based on the thread it sounds like what people actually want is isolation and access control, but I don’t think that responsibility should fall on the app developer, it should be handled by a broader system (like Veracrypt, or Flatpak).

It doesn’t have to be, but if all Linux apps were standalone binaries, installing apps would be a PITA. Flatpaks have better integration with the desktop environment (like automatically handling desktop shortcuts), can share runtimes to save space, have a standardized way of handling permissions and launch options, etc. The Linux world is moving towards flatpaks for many reasons, and the Tor Browser flatpak is marked as official from the Tor Project. Wouldn’t it be reasonable to expect it to work, and to get some sort of notification if it breaks?

That was an eye-opening read, especially the part about Briar. I can understand closing an issue to reduce developer load, but deleting it to censor mentions of specific apps? Almost dystopian. Thanks for keeping an open mind, it’s essential if you want to survive in the privacy and security community, which is so full of drama and ego.

Sorry I just read the GrapheneOS thread on the F-Droid signature pinning issue (the same issue I linked in the last paragraph of my first comment in fact), and I just wanted to add some comments. While I agree with most of the discussion there, the problem is that the alternatives are worse. Obtainium just pulls binaries directly from Github, where developer accounts have been compromised before. The Play Store has tons of malicious apps.

One of the main benefits of F-Droid is that they have standards. If you get an app from the default F-Droid repo, you can be reasonably certain that it is open-source and private. There are many apps like Bitwarden that couldn’t get included, and when you read the F-Droid Gitlab discussions on why, there are always good reasons. F-Droid will also warn you about telemetry and tracking, even if the app makes it into the default repo. These are things that Obtainium or the Play Store simply don’t provide.

The official GrapheneOS account wrote:

F-Droid automatically downloads and builds code, so despite their false marketing it does not protect users from the developers in any real way

Yes this does protect users. As I’ve mentioned before, it’s all too common for developers to sell their project to malicious third parties (often happens for browser extensions), or for developer accounts to be compromised (often happens for software packages, like NPM or PyPI). In these cases, the attackers will almost always change the pre-compiled binaries without updating the published source code. The only way to defend against this is via reproducible builds. F-Droid has been pushing for this, and the number of apps supporting reproducible builds has been growing year by year. Still, even without reproducible builds, I would rather trust F-Droid to protect their signing keys and accounts, rather than trust every app developer to do the same. After all, it only takes one compromised developer to compromise your phone.

Lastly, in the same comment by the GrapheneOS account, they said

If you continue to misrepresent, downplay and deny the many real issues about F-Droid, you’ll no longer be participating in our community.

This is very worrying to me, and makes me wary to participate in their community in the first place. As I just explained above I don’t agree with their logic, and now I see that this person is flaunting the fact that they can ban people for whatever they consider “misrepresentation”? I hope that the GrapheneOS community will recognize the dangers of centralizing all moderation power to somebody who seems so self-righteous.

Anyways I just wanted to share my thoughts on the thread, but thanks for the discussion as well, I bookmarked a lot of the links you shared and will be sharing them in the future!

secureblue includes modified images of CoreOS called securecore. While this doesn’t fix the issue you described, it is worth mentioning as a (technically) more secure option than both Debian and CoreOS.

Honestly I would not recommend securecore or secureblue for security. Small team, no track record, very little funding. I doubt their patches are audited by third-parties, and their userbase is probably so small that bugs are not found quickly. I’m sure you’ve already seen this PrivacyGuides thread on secureblue but the project is still very unstable. Their ideas may sound nice in theory, but patches can end up introduces more vulnerabilities than they fix. There are going to be breakages, changes in recommendations, bugs, regressions, and all of these impact security. I would not recommend it until their userbase is larger. You might ask how their userbase could ever get larger by my logic, which is why I’ll say that I’ll only recommend it for users who care about contributing and supporting the project, and improving the security of the future, even if it means sacrificing a bit of their own security at the present.

From my experience, having a large userbase and strong track record are the most reliable indicators for good security. You can always find articles criticizing old projects for security issues, but that’s simply because new projects aren’t under the same scrutiny (GrapheneOS is a rare exception). This is why I recommend Fedora Workstation/Silverblue over secureblue, Debian over CoreOS and securecore, and F-Droid over Accrescent. Though if you want to fight for a better future and test drive the hot new stuff, all the power to you.

First off, props on the detailed and informative post. I’ve never seen a post so packed with links and citations. I’d just like to share some of my own experience:

In regards to Debian vs atomic distros. First off, most recommendations for Debian are recommending it for use on the server. I definitely agree that on the desktop, you are better off with a more up-to-date distro, especially for browser patches. But for the server, after having used both Debian and Fedora CoreOS (an atomic distro for servers) for over a year each, I trust Debian more in terms of security and stability. For example, last summer when there was a major OpenSSH vulnerability, Debian had already patched it, because the security researchers had notified the Debian maintainers prior to the announcement. CoreOS on the other hand, took multiple weeks to release the fix. I also ran into some coredumps on Fedora CoreOS. It was only once or twice, but I never experienced the same on Debian. The main reason why I trust Debian is simply because it’s an industry standard. Billions if not trillions of dollars are on the line if Debian is compromised. CoreOS and atomic distros are just not popular enough to receive nearly as much attention. There’s safety in numbers. That’s why for the server, I’d recommend Debian, while for the desktop, Ubuntu or Fedora are better choices. Though if you really want security on the server, I would recommend Proxmox, which uses a similar security model as Qubes. Note that Proxmox is based on Debian.

As for the topic of F-Droid, you brought up the PrivSec article on F-droid security issues. This article is a few years old and is always brought up in criticisms against F-Droid. My main problem with it is that it downplays the importance of open source. One thing not mentioned in the article is that ideally, you shouldn’t even need to trust the developer. That’s one of the benefits of open source. Those familiar with the world of browser extensions are also all too familiar with how often the developer sells the project to a malicious party, who can then backdoor the published extension without updating the source code. Now, open source is only secure if it’s audited, something you mentioned in your post, but in my experience just the fact that it can be audited is good enough to scare away bad actors. Afaik F-Droid has had zero malware. Despite being a small store, that’s still extremely impressive, and speaks for itself. There is still the danger that F-Droid itself is compromised, but that can be solved with reproducible builds, which is something the Play Store can’t offer due to Play App Signing, while F-Droid is pushing for it.

Though that is just in theory. I should mention that there was a pretty worrying issue found in F-Droid reproducible builds recently. I still trust the security of F-Droid more than the Play Store though.