Interesting thoughts about privacy, security, and all the things
I'm making this post to share some interesting less talked about things about privacy, security, and other related topics. This post has no direct goal, it's just an interesting thing to read. Anyways, here we go:
I made a post about secureblue, which is a Linux distro* (I'll talk about the technicality later) designed to be as secure as possible without compromising too much usability. I really like the developers, they're one of the nicest, most responsible developers I've seen. I make a lot of bug reports on a wide variety of projects, so they deserve the recognition.
Anyways, secureblue is a lesser known distro* with a growing community. It's a good contrast to the more well known alternative** Qubes OS, which is not very user friendly at all.
* Neither secureblue, nor Qubes OS are "distros" in the classical sense. secureblue modifies and hardens various Fedora Atomic images. Qubes OS is not a distro either, as they state themselves. It's based on the Xen Hypervisor, and virtualizes different Linux distros on their own.
** Qubes OS and secureblue aren't exactly comparable. They have different goals and deal with security in different ways, just as no threat model can be compared as "better" than any other one. This all is without mentioning secureblue can be run inside of Qubes OS, which is a whole other ballpark.
secureblue has the goal of being the most secure option "for those whose first priority is using Linux, and second priority is security." secureblue "does not claim to be the most secure option available on the desktop." (See here) Many people in my post were confused about that sentence and wondered what the most secure option for desktop is. Qubes OS is one option, however the secureblue team likely had a different option in mind when they wrote that sentence: Android.
secureblue quotes Madaiden's Insecurities on some places of their website. Madaiden's Insecurities holds the view that Linux is fundamentally insecure and praises Android as a much better option. It's a hard pill to swallow, but Madaiden's Insecurities does make valid criticisms about Linux.
However, Madaiden's Insecurities makes no mention of secureblue. Why is that? As it turns out, Madaiden's Insecurities has not been updated in over 3 years. It is still a credible source for some occasions, but some recommendations are outdated.
Many people are strictly anti-Google because of Google's extreme history of privacy violations, however those people end up harming a lot of places of security in the process. The reality is, while Google is terrible with privacy, Google is fantastic with security. As such, many projects such as GrapheneOS use Google-made devices for the operating system. GrapheneOS explains their choice, and makes an important note that it would be willing to support other devices as long as it met their security standards. Currently only Google Pixels do.
For those unfamiliar, GrapheneOS is an open source privacy and security focused custom Android distribution. The Android Open Source Project (AOSP) is an open source project developed by Google. Like the Linux kernel, it provides an open source base for Android, which allows developers to make their own custom distributions of it. GrapheneOS is one such distribution, which "DeGoogles" the device, removing the invasive Google elements of the operating system.
Some Google elements, such as Google Play Services can be optionally installed onto the device in a non-privileged way (see here and here). People may be concerned that Google Pixels can still spy on them at a hardware level even with GrapheneOS installed, but that isn't the case.
With that introduction of secure Android out of the way, let's talk about desktop Android. Android has had a hidden option for Desktop Mode for years now. It's gotten much better since it was first introduced, and with the recent release of Android 15 QPR2, Android has been given a native terminal application that virtualizes Linux distros on the device. GrapheneOS is making vast improvements to the terminal app, and there are many improvements to come.
GrapheneOS will also try to support an upcoming Pixel Laptop from Google, which will run full Android on the desktop. All of these combined means that Android is one of, if not the, most secure option for desktop. Although less usable than some more matured desktop operating systems, it is becoming more and more integrated.
By the way, if you didn't know, Android is based on Linux. It uses the Linux kernel as a base, and builds on top of it. Calling Qubes OS a distro would be like calling Android and Chrome OS distros as well. Just an interesting fact.
So, if Android (or more specifically GrapheneOS) is the most secure option for desktop, what does that mean in the future? If the terminal app is able to virtualize Linux distros, secureblue could be run inside of GrapheneOS. GrapheneOS may start to become a better version of Qubes OS, in some respects, especially with the upcoming App Communication Scopes feature, which further sandboxes apps.
However, there is one bump in the road, which is the potential for Google to be broken up. If that happens, it might put GrapheneOS and a lot of security into a weird place. There might be consequences such as Pixels not being as secure or not supporting alternative Android distributions. Android may suffer some slowdowns or halts in development, possibly putting more work on custom Android distribution maintainers. However, some good may come from it as well. Android may become more open source and less Google invasive. It's going to be interesting to see what happens.
Speaking of Google being broken up, what will happen to Chrome? I largely don't care about what happens to Chrome, but instead what happens to Chromium. Like AOSP, Chromium is an open source browser base developed by Google. Many browsers are based on Chromium, including Brave Browser and Vanadium.
Vanadium is a hardened version of Chromium developed by GrapheneOS. Like what GrapheneOS does to Android, Vanadium removes invasive Google elements from the browser and adds some privacy and security fixes. Many users who run browser fingerprinting tests on Vanadium report it having a nearly unique fingerprint. Vanadium does actually include fingerprint protections (see here and here), but not enough users use it for it to be as noticeable as the Tor Browser. "Vanadium will appear the same as any other Vanadium on the same device model, and we don't support a lot of device models." (see here)
There's currently a battle in the browser space between a few different groups, so mentioning any browser is sure to get you involved in a slap fight. The fights usually arise between these groups:
- The group that is strictly anti-Google and uses Firefox-based browsers
- The security focused group that recognizes that Firefox is insecure and opts for privacy enhanced versions of Chromium
- The political group that only care about the politics behind an organization rather than the code itself (examples: Firefox Terms of Use update, Brave Browser including a crypto wallet)
For that last one, I would like to mention that Firefox rewrote the terms after backlash, and users have the ability to disable bloatware in Brave. Since Brave is open source, it is entirely possible for someone to make a fork of it that removes unwanted elements by default, since Brave is another recommended browser by the GrapheneOS team for security reasons.
Another interesting Chromium-based browser to look at is secureblue's Trivalent, which was inspired by Vanadium. It's a good option for users that use Linux instead of Android as a desktop.
Also, about crypto, why is there a negativity around it? The reason is largely due to its use in crime, use in scams, and use in investing. However, not all cryptocurrencies are automatically bad. The original purpose behind cryptocurrency was to solve a very interesting problem.
There are some cryptocurrencies with legitimate uses, such as Monero, which is a cryptocurrency designed to be completely anonymous. Whether or not you invest in it is your own business, and unrelated to the topics of this post. Bitcoin themselves even admit that Bitcoin is not anonymous, so there is a need for Monero if you want fully decentralized, anonymous digital transactions.
On the topic of fully decentralized and anonymous things, what about secure messaging apps? Most people, even GrapheneOS and CISA, are quick to recommend Signal as the gold standard. However, another messenger comes up in discussion (and my personal favorite), which is SimpleX Chat.
SimpleX Chat is recommended by GrapheneOS occasionally, as well as other credible places. This spreadsheet is my all time favorite one comparing different messengers, and SimpleX Chat is the only one that gets full marks. Signal is a close second, but it isn't decentralized and it requires a phone number.
Anyways, if you do use Signal on Android, be sure to check out Molly, which is a client (fork) of Signal for Android with lots of hardening and improvements. It is also available to install from Accrescent.
Accrescent is an open source app store for Android focused on privacy and security. It is one of the default app stores available to install directly on GrapheneOS. It plans to be an alternative to the Google Play Store, which means it will support installing proprietary apps. Accrescent is currently in early stages of development, so there are only a handful of apps on there, but once a few issues are fixed you will find that a lot of familiar apps will support it quickly.
Many people have high hopes for Accrescent, and for good reason. Other app stores like F-Droid are insecure, which pose risks such as supply chain attacks. Accrescent is hoped to be (and currently is) one of the most secure app stores for Android.
The only other secure app store recommended by GrapheneOS is the Google Play Store. However, using it can harm user privacy, as it is a Google service like any other. You also need an account to use it.
Users of GrapheneOS recommend making an anonymous Google account by creating it using fake information from a non-suspicious (i.e. not a VPN or Tor) IP address such as a coffee shop, and always use a VPN afterwards. A lot of people aren't satisfied with that response, since the account is still a unique identifier for your device. This leads to another slap fight about Aurora Store, which allows you to (less securely) install Play Store apps using a randomly given Google account.
The difference between the Play Store approach and the Aurora Store approach is that Aurora Store's approach is k-anonymous, rather than... "normal" anonymity. The preference largely comes down to threat models, but if you value security then Aurora Store is not a good option.
Another criticism of the Play Store is that it is proprietary. The view of security between open source software and proprietary software has shifted significantly. It used to be that people viewed open source software as less secure because the source code is openly available. While technically it's easier to craft an attack for a known exploit if the source code is available, that doesn't make the software itself any less secure.
The view was then shifted to open source software being more secure, because anyone can audit the code and spot vulnerabilities. Sometimes this can help, and many vulnerabilities have been spotted and fixed faster due to the software being open source, but it isn't always the case. Rarely do you see general people looking over every line of code for vulnerabilities.
The reality is that, just because something is open source, doesn't mean it is automatically more or less secure than if it were proprietary. Being open source simply provides integrity in the project (since the developers make it as easy as possible to spot misconduct), and full accountability towards the developers when something goes wrong. Being open source is obviously better than being proprietary, that's why many projects choose to be open source, but it doesn't have to be that way for it to still be secure.
Plus, the workings of proprietary code can technically be viewed, since some code can be decompiled, reverse engineered, or simply read as assembly instructions, but all of those are difficult, time consuming, and might get you sued, so it's rare to see it happen.
I'm not advocating for the use of proprietary software, but I am advocating for less hate regarding proprietary software. Among other things, proprietary software has some security benefits in things like drivers, which is why projects like linux-libre and Libreboot are worse for security than their counterparts (see coreboot).
Those projects still have uses, especially if you value software freedom over security, but for security alone they aren't as recommended.
Disclaimer before this next section: I don't know the difference in terminology between "Atomic", "Immutable", and "Rolling Release", so forgive me for that.
Also, on the topic of software freedom, stop using Debian. Debian is outdated and insecure, and I would argue less stable too. Having used a distro with an Atomic release cycle, I have experienced far less issues than when I used Debian. Not to mention, if you mess anything up on an Atomic distro, you can just rollback to the previous boot like nothing happened, and still keep all your data. That saved me when I almost bricked my computer motifying /etc/fstab/ by hand.
Since fixes are pushed out every day, and all software is kept as up to date as possible, Atomic distros I argue give more stability than having an outdated "tried and tested" system. This is more an opinion rather than factually measured.
Once I realized the stable version of Debian uses Linux kernel 6.1, (which is 3 years old and has had actively exploited vulnerabilities), and the latest stable version of the kernel is 6.13, I switched pretty quick for that reason among others.
Now, many old kernel versions are still maintained, and the latest stable version of Android uses kernels 6.1 and 6.6 (which are still maintained), but it's still not great to use older kernel versions regardless. It isn't the only insecurity about Debian.
I really have nothing more to say. I know I touched on a lot of extremely controversial topics, but I'm sick of privacy being at odds with security, as well as other groups being at odds with each other. This post is sort of a collection of a lot of interesting privacy and security knowledge I've accrued throughout my life, and I wanted to share my perspective. I don't expect everybody to agree with me, but I'm sharing this in case it ever becomes useful to someone else.
Thanks for taking the time to read this whole thing, if you did. I spent hours writing it, so I'm sure it's gotten very long by now.
Happy Pi Day everyone!
secureblue: Hardened Fedora Atomic and Fedora CoreOS images
cross-posted from: lemmy.ml/post/26453685Not many people have heard about secureblue, and I want to spread the word about it. secureblue provides hardened images for Fedora Atomic and CoreOS. It's an operating system "for those whose first priority is using linux, and second priority is security."secureblue provides exploit mitigations and fixes for multiple security holes. This includes the addition of GrapheneOS's hardened_malloc, their own hardened Chromium-based browser called Trivalent, USBGuard to protect against USB peripheral attacks, and plenty more.
secureblue has definitely matured a lot since I first started using it. Since then, it has become something that could reasonably be used as a daily driver. secureblue recognizes the need for usability alongside security.
If you already have Fedora Atomic (e.g. Secureblue, Kinoite, Sericea, etc.) or CoreOS installed on your system, you can easily rebase to secureblue. The install instructions are really easy to follow, and I had no issues installing it on any of my devices.
I'd love more people to know about secureblue, because it is fantastic if you want a secure desktop OS!
secureblue: Hardened Fedora Atomic and Fedora CoreOS images
Hardened operating system images based on Fedora Atomic Desktop and Fedora CoreOSsecureblue
Walking Coffin
in reply to The 8232 Project • • •Thank you for taking the time to write all this.
First of all, you do touch up on some good topics with sources and I appreciate that. However I would like to say that you may have either oversimplified or misunderstood some concepts you talk about here. Just so we're clear, the whole topic of privacy/security is vast and knowing everything about it all is impossible so this is not an insult but a simple remark.
While I will not tackle everything you mentionned, mainly because you have your opinion, which is valid, and you do bring up good points, I will point out the last two topics you bring up.
Debian is indeed less secure than a stable release Linux distribution based on sane defaults, however they do backport security issues into their older kernel which is how older kernels are maintained. So while yes, they may still use kernel 6.1, they also may have backported 6.12 vulnerability fixes.
The last topic you end up with is the constant fact that some "groups being at odds with each other" and "privacy being at odds with security". Groups being at odds is not all good and neither is it all bad. Just like Lemmy or federation, it brings diversity in an ecosystem that needs said diversity.
You yourself bring up project 1 and compare it to project 2 at first while they are so different that comparing the two is like saying that an orange is blue. Many people will stop there and you went a deeper and properly laid out that it wasn't the case but you fail to do so some place else.
Like I said, all of this is a very vast topic. However, while you have "fights" and groups being at odds with each other for sometimes good or not so good reasons, it brings out one of the best things in open source sometimes. "I dont like you or the way you handle that project so I'm going to make my own fork of it and do it my way".
Thank you for your time and I do hope your text will help some people out.
The 8232 Project
in reply to Walking Coffin • • •Hey, thanks for this!
Mostly oversimplification. However, I don't know everything and do make mistakes like everyone else.
I acknowledged this in this comment.
This is true, but there needs to be more constructive discourse rather than directly attacking different viewpoints. People who say they use Brave on Lemmy often get lynched pretty quickly, for example.
Walking Coffin
in reply to The 8232 Project • • •I definitely agree that more constructive discourse needs to take place instead of some needless fights that happen way too often.
About Brave and the view some lemmy users express about it, I feel some of the distrust is valid while the way many express it is with no other regards to the good there might be or without any technical knowledge behind words being shared around. Exactly how you mentioned Google being awful at privacy but great at security.
Broken
in reply to The 8232 Project • • •The 8232 Project
in reply to Broken • • •Thank you!
I saw your comment before you edited it, saying you hadn't heard of Trivalent before. Trivalent is a browser developed by secureblue, and is the main browser for that OS. It was renamed a while back from
hardened-chromium. It's not easy to install on systems other than secureblue, but it is possible.Release v4.4.0 - hardened-chromium is now Trivalent! · secureblue/secureblue
GitHubtoastal
in reply to The 8232 Project • • •The 8232 Project
in reply to toastal • • •You can get 3.5 mm to USB-C adapters for relatively cheap, or buy direct USB-C wired headphones. GrapheneOS allows you to restrict the permissions of the USB-C port to your needs. Alternatively, just use wireless earbuds, if you don't care about the security issues with Bluetooth. GrapheneOS also includes automatically disabling Bluetooth after a timeout when it's not in use.
In my opinion, the security benefits of GrapheneOS far outweigh the need for a 3.5 mm headphone jack.
Linux phones are wildly insecure.
USB-C Digital Earbuds for Pixel Phones
Google Storetoastal
in reply to The 8232 Project • • •The adaptors are flimsy and hang funny. Both of these options are putting additional strain on the only port for charging & data transfer—which is also making you choose audio or charging / transfer. Or they want to push you into buying irrepairable, flaky, branded earbuds what generally have worse audio quality & always having latency. When all non-phone devices are still understandably using the standard 3.5 mm jack, why give any money & reward these companies putting out devices with user-unfriendly IO when I can support one that does meet my needs?
You can make Linux more secure by various means, & we will never get to a better state until early adopters start adopting the ecosystems. I would rather do this than support more Google ecosystem stuff.
GrapheneOS doesn’t really give you choice. This isn’t cool to me—& you will have a hard time convincing me otherwise since there are plenty of precautions I can take with my setups & my threat models without being told there is only one option.
aprehendedmerlin
in reply to The 8232 Project • • •The 8232 Project
in reply to aprehendedmerlin • • •Thank you!
I'm open to discussion, if you want to!
aprehendedmerlin
in reply to The 8232 Project • • •The 8232 Project
in reply to aprehendedmerlin • • •Besides Linux being fundamentally insecure (as I mentioned early on in my post), Debian focuses on stability by providing a set of software that is thoroughly tested but does not change for years. While they do provide security fixes for a lot of software, the reality is that using outdated software in any capacity is a security risk of its own, and is bound to provide bugs that harm stability. Comparing Debian to bleeding-edge distros like Fedora, which focuses on security, it's clear the differences in security between them.
Fedora Linux
fedoraproject.orgaprehendedmerlin
in reply to The 8232 Project • • •The 8232 Project
in reply to aprehendedmerlin • • •For a beginner distro, definitely don't use secureblue. While it is user friendly to use, it's pretty difficult to install properly and requires a bit of knowledge about Linux to do so.
The ideal roadmap I would give to people trying out Linux for the first time would be this:
If you use MacOS: Buy a new laptop and install Ubuntu
If you use Windows 11: Install Kubuntu. Get used to using Linux using that, and, when you're ready, transition to Ubuntu
If you use Windows 10: Install Linux Mint. Get used to using Linux using that, and, when you're ready, install Kubuntu. Get used to using that, then, when you're ready again, transition to Ubuntu.
After you've gotten used to Ubuntu and feel ready, install Fedora Workstation.
Once you are used to a Fedora-based distro, you can try out Fedora Silverblue.
After learning Fedora Atomic, you can rebase to secureblue without issue.
(Windows 10 -> ) Linux Mint -> (Windows 11 -> ) Kubuntu -> (MacOS -> ) Ubuntu -> Fedora Workstation -> Fedora Silverblue -> secureblue
It should give you a well rounded knowledge of Linux and an easy, slow transition to more secure distros. Really the important thing when starting with Linux is using a desktop environment that is most familiar to what you already are used to. Desktop environments are the "looks" of Linux.
Each transition in the roadmap teaches you something new about Linux to get used to.
Good luck!
Plasma
Plasmashaserlark
in reply to The 8232 Project • • •The 8232 Project
in reply to shaserlark • • •Bleeding edge distros (especially Fedora Atomic distros and especially especially secureblue) tend to have less documentation and less people available to help. secureblue is currently so obscure that the best way to get help is by using their Discord or contacting the developers directly. This makes it difficult for users using Linux for the first time to fix basic issues that arise simply from never using Linux before.
As I mentioned in my post, Linux is fundamentally insecure. secureblue is almost as secure as Linux gets, but it's only a couple steps away from desktop Android, so I would just opt for that if you can. Fedora and (especially) Fedora Atomic are bleeding edge, meaning they adopt newer, more secure software sooner, making them more modern, up to date, and secure than other distros.
I oversimplified things a bit here, so let me know if you have any other questions!
Contributing | secureblue
secureblueshaserlark
in reply to The 8232 Project • • •No I get that, thanks a lot for explaining! I work with a bunch of other stuff where help is mostly also only available on discord so that’s fine.
I really need to read into the whole Android stuff more. I know privacy and security are different topics, it’s just a weird thing to wrap my head around that Android would be the most secure option.
Another issue is that for what I’m doing I need to rent VPSes and there you’re already quite limited as to what you can run on them, probably Android wouldn’t be an option right? And let’s say I want to deploy some apps there would this work on Android out of the box? I know it’s Linux under the hood I’m just not really deep into the more advanced Linux stuff tbh.
The 8232 Project
in reply to shaserlark • • •An easy way to imagine it is that all apps on Android have permission control. That's only available on Linux through Flatpaks, but Flatpaks have issues of their own.
Probably not, at least not yet. Android runs on a specific instruction set (ARM chips), so you'll find it difficult finding a place that hosts those. It's a growing standard, though. Even then, proper security on Android relies on GrapheneOS, which itself only runs on Pixel devices (for now).
With the Linux terminal added to Android, technically yes. However, it's still quite experimental, and you'll need to do some specific configuration to get it working properly.
No worries! Do check out this post where people share things they have hosted on Android. It's mostly hosted from the Termux app, rather than the new terminal.
If you want to host a server securely and with at least some documentation, do try Qubes OS or securecore (made by secureblue).
Flatpak | secureblue
secureblueaprehendedmerlin
in reply to The 8232 Project • • •Broken
in reply to aprehendedmerlin • • •Just as a tip, set up and use a spare machine if you have one to make the transition easier. I've been running Mint now for a few months.
I have a test machine that I am learning and getting familiar with, setting up a virtual machine to learn that (I have some windows apps I will not escape from so running in a VM is my solution), etc... And all of this is with the freedom that if I break something I can wipe it and not care. I have since set up a media center and a gaming machine as well.
That experience is getting me feeling better about he whole thing. Honestly learning little idiosyncrasies like folder permissions not being inherited (I say as I set up my media center) are the things you juat need to learn through practice. Just my two cents as I am only a step ahead of you in a similar journey.
The 8232 Project
in reply to Broken • • •I'm getting flashbacks... If you feel like living on the dangerous side, don't be afraid to bork all your security and
chmod -R 777 /!(This is a joke. Don't actually run that)
Why Is chmod -R 777 / Destructive? | Baeldung on Linux
Ali Imran Nagori (Baeldung)Broken
in reply to The 8232 Project • • •Don't kid. I did that with a folder in my testing just to eliminate the variables. Of course I put it back.
My issue was that my initial setup was accessing it from a different machine, and windows at that. I had to simplify in order to make it all mentally make sense.
nikqwxq550
in reply to The 8232 Project • • •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.
F-Droid Security Issues
PrivSec.dev Contributors (PrivSec - A practical approach to Privacy and Security)The 8232 Project
in reply to nikqwxq550 • • •Hello there!
It's nice to see some constructive discussions going on, thank you for that!
Madaiden’s Insecurities admits that Linux is more secure when run on a server for various reasons, so I didn't really focus on the server side of things. I'll talk more about this in a bit. I do think Debian is better suited for a server rather than a desktop, but I see Debian recommended countless times for desktop use as well.
Nice to see someone who has experienced both!
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. Qubes OS can also be run as a server, and that's what Let's Encrypt uses for their servers.
I can't speak in terms of stability, since the most I've done is a couple Docker containers on a Raspberry Pi.
This was actually my first time doing proper research on the F-Droid insecurity issues, so I went with the sources I thought were most credible. Privacy Guides also recommends against using F-Droid's main client in some cases.
F-Droid has had issues with certificate pinning, and this whole thread has a lot of things against F-Droid.
It's a deep rabbit hole that I don't quite want to spend time digging through.
F-Droid Security Issues
PrivSec.dev Contributors (PrivSec - A practical approach to Privacy and Security)nikqwxq550
in reply to The 8232 Project • • •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.
Secureblue - Atomic Fedora Hardening
Privacy Guides CommunityThe 8232 Project
in reply to nikqwxq550 • • •nikqwxq550
in reply to The 8232 Project • • •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:
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
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!
F-Droid vulnerability allows bypassing certificate pinning - GrapheneOS Discussion Forum
GrapheneOS Discussion ForumThe 8232 Project
in reply to nikqwxq550 • • •Do check out this amusing post. The GrapheneOS team has a long history of being kind of a dick. It sucks, but there's no alternative mobile OS as secure, so it's currently a necessary evil. I even talk about the community in this post. They are seldom open minded, which is a trap many people who share their ideas fall into. I recognized this early on, so I choose to adopt their ideas but keep an open mind and open heart about other differing ideas (as best I can).
I was debating making a part 2 to this post, because one topic I wanted to talk about is Briar. Briar is a messaging app with the ability to work offline over Bluetooth. I don't think it's as secure as Signal or SimpleX Chat, but I recognize that there is a proper use case for it.
I once opened an issue on GrapheneOS's issue tracker, asking for a way to install GrapheneOS offline from another GrapheneOS device. Tails and Briar both include that functionality. GrapheneOS completely deleted the issue (not just closed, but fully deleted) and (after an extreme amount of prying) I was able to find out that they removed it because they don't want to endorse Briar in any way.
You can actually check how many issues GrapheneOS has deleted by adding up the number of open issues/PRs (currently 725) to the number of closed issues/PRs (currently 3,941) which currently adds to 4,666. Subtract that number from the number of the latest issue/PR (currently #5708) and you get 1,042 deleted issues (~18.26%).
That might sound like a lot, but I measured the percentage of deleted issues from other big repos, and it's about standard.
Me too. I do think there is a place for strict perfectionism in the context of security, but there are better ways to go about it. Not everyone on the GrapheneOS team is as bad, thankfully. Most people in the GrapheneOS community are quite nice and welcoming.
Secure messaging, anywhere - Briar
briarproject.orgThe 8232 Project
2024-09-27 01:47:15
nikqwxq550
in reply to The 8232 Project • • •ganymede
in reply to The 8232 Project • • •excellent writeup with some high quality referencing.
minor quibble
i'm not sure many people would disagree with you that FF is less secure than Chromium (hardly a surprise given the disparity in their budgets and resources)
though i'm not sure it's fair to say FF is insecure if we are by comparison inferring Chromium is secure? ofc Chromium is more secure than FF, as your reference shows.
another minor quibble
does this read like coreboot is proprietary? isn't it GPL2? i might've misunderstood something.
you make some great points about open vs closed source vs proprietary etc. again, it shouldn't surprise us that many proprietary projects or Global500 funded opensource projects, with considerably greater access to resources, often arrive at more robust solutions.
i definitely agree you made a good case for the currently available community privacy enhanced versions based on open source projects from highly commercial entities (Chromium->Vanadium, Android/Pixel->GrapheneOS) etc. something i think to note here is that without these base projects actually being opensource, i'm not sure eg. the graphene team would've been able to achieve the technical goals in the time they have, and likely with even less success legally.
so in essence, in the current forms at least, we have to make some kind of compromise, choosing between something we know is technically more robust and then needing to blindly trust the organisation's (likely malicious) incentives. therefore as you identify, obviously the best answer is to privacy enhance the project, which does then involve some semi-blind trusting the extent of the privacy enhancement process - assuming good faith in the organisation providing the privacy enhancement: there is still an implicit arms race where privacy corroding features might be implemented at various layers and degrees of opacity vs the inevitably less resourced team trying to counter them.
is there some additional semi-blind 'faith' we're also employing where we are probably assuming the corporate entity currently has little financial incentive in undermining the opensource base project because they can simply bolt on whatever nastiness they want downstream? it's probably not a bad assumption overall, though i'm often wondering how long that will remain the case.
and ofc on the other hand, we have organisations who's motivation we supposedly trust (mostly...for now), but we know we have to make a compromise on the technical robustness. eg. while FF lags behind the latest hardening methods, it's somewhat visible to the dedicated user where they stand from a technical perspective (it's all documented, somewhere). so then the blind trust is in the purity of the organisation's incentives, which is where i think the political-motivated wilfully-technically-ignorant mindset can sometimes step in. meanwhile mozilla's credibility will likely continue to be gradually eroded, unless we as a community step up and fund them sufficiently. and even then, who knows.
there's certainly no clear single answer for every person's use-case, and i think you did a great job delineating the different camps. just wanted to add some discussion. i doubt i'm as up to date on these facets as OP, so welcome your thoughts.
fucking well said.
The 8232 Project
in reply to ganymede • • •Thank you!
The whole debate is a mess, so at some point you have to pick a camp of thinking and stick to it. I tried to clear this up before, but failed:
- lemmy.ml/post/21367269
- lemmy.ml/post/21887275
Good question! I should have clarified. Libreboot removes proprietary drivers, firmware, and other code from coreboot in favor of their open source counterparts (where available). Some of that code is used to keep the system secure, even if it is proprietary, so Libreboot favors open source over security.
Most Google BS is simply not included in AOSP at all, and is instead added to their own proprietary Pixel OS (based on AOSP). For the invasive bits that are included, it's easy enough for GrapheneOS to look over the incremental updates in Android and remove the bits that they don't like.
The 8232 Project
2024-10-14 02:20:01
ganymede
in reply to The 8232 Project • • •Thanks for the distinctions and links to the other good discussions you've started!
That's my approximate take as well, but it wasn't quite what I was getting at.
What I meant is, to ask ourselves why is that the case? A LOT of it is because google wills it to be so.
Not only in terms of keeping it open, but also in terms of making it easy or difficult - it's almost entirely up to google how easy or hard it's going to be. Right now we're all reasonably assuming they have no current serious incentives to change their mind. After all, why would they? The miniscule % of users who go to the effort of installing privacy enhanced versions of chromium (or android based os), are a tiny drop in the ocean compared to the vast majority of users running vanilla and probably never even heard of privacy enhanced versions.
Lonewolfmcquade
in reply to The 8232 Project • • •Well said! I really enjoyed reading this post. I've been interested in this topic for over 20 years but I feel like you delivered a bleeding edge analysis of the current state of affairs much better than anything else I've read. In particular, this post and the supporting docs crystallized the difference between privacy and security for me. I'm interested in both but had taken it for granted that enhancing privacy always benefitted security. Now I see how my own personal desire for control over my systems does involve some trade-off with security. There is a lot of food for thought here!
Unfortunately, I don't appreciate any of the current options for a more secure desktop. I hate the direction Microsoft is taking Windows since 8.1. I'm familiar with the telemetry workarounds and found them to be volatile and fussy; it feels like I'm constantly swimming against the tide with them. And the new forced update paradigm is terrible. All too often their forced updates either remove functionality, control, or features, if not straight up break my system - worse than any Linux experience I've had. Not to mention forcing ads and "AI" into everything. Basically I don't want to be an obligate beta tester or constantly manage workarounds for "features" I didn't agree to. I could go on and on.
In my opinion, the Mac ecosystem is similarly terrible with respect to user control and transparency. I loved Mac back in the early 00s but since then I find them infuriating to use whenever I encounter a seemingly solvable problem. And I hate feeling trapped by a corporate ecosystem.
Google isn't much different from the other two, with the additional issues of privacy violations, incompetent (if not hostile) leadership and anti-consumer behavior.
Qubes sounds problematic at best but I may explore secureblue. I had a terrible time with Fedora when I gave it a go last year. Trying to encrypt the boot drive with BTRFS and Snapper was apparently beyond my patience.
I'd love to see an Arch based distro take up the task of creating a security and privacy focused spin. And I eagerly await the day that Graphene works well on devices other than Pixels. That would be ideal to me.
I've saved your post and will be re-reading it. I would vote to make this a sticky for the near term, if that were a thing. Thank you!
marauding_gibberish142
in reply to The 8232 Project • • •I largely agree. Qubes may not be as user friendly as others, but honestly I think it is the only OS which can get close to Android's level of security (of course, by taking a hammer to most privilege escalation problems).
I have heard about Accrescent but I'll wait till it gets more popular before I jump.
Google being broken up might mean the beginning of a demise of both Chromium and Firefox. So we better get on a new engine quick or things are about to get a lot worse.
Unfortunately, I have not found a better way to install the few playstore apps that I need without Aurora store. I guess using it in a different namespace (is that what Shelter does?) is an option.
Great note