But then again some people use things like Homebrew and pacstall unironically so …

Thank you for mentioning this! Unfortunately a quick search on the internet didn’t yield any pointers. Would you mind elaborating upon the security problems of Homebrew(/Linuxbrew)? Thanks in advance 😊!

Yeah know that deleting post fun. Jerboah is very good at recovering them.

TIL about Jerboa. Thank you!

If you use your GPU that model is fingerprintable through WebGL stuff. There is a firefox addon that spoofs random values though. Same for screen size.

IIRC, so-called ‘naive scripts’ will indeed be spoofed. However, it has been shown at great length that JavaScript is not even required to to acquire screen size in the first place. Furthermore, methods that rely on badness enumeration are deemed inferior.

Secureblue does not implement privacy over security, but if patches make a browser stay just as securely I think that would be fine.

That would require someone to put effort into showing that ungoogled-chromium is at least as secure as Chromium. Is that even established in the first place?

The thing is, for example we had some arguments about manifest v2 extensions (which can download stuff they then use, i.e. no control by Google and thus “less secure”). If Chromium does things like Connect to Google for security stuff like Safe Browsing, this will totally not be removed.

Perhaps the desire to minimize attack surface is what’s been decisive.

Secureblue is not GrapheneOS too. It is just a (huge) compilation of patches and patched images. Basically every Desktop with Wayland support, currently 86 (!!!) images.

Surely, it would take a lot more effort to get it to GrapheneOS levels. However, I don’t find any fault with the desire to be inspired from GrapheneOS’ methods and implementations.

First of all, apologies for the late response. I had written a response, but something happened before I sent it and the cache of my phone wasn’t able to recollect my writing. I got so discouraged by this that I didn’t bother with it right away.

QubesOS is interesting, I think overcomplex but needed until better systems are in place.

Well said!

Bubblejail would be an alternative that runs on normal hardware.

I hope Bubblejail will indeed reach the level of sandboxing solutions we find on e.g. mobile devices. Though, a lot of work has to be put into portals (and others) before a feat as such is achieved.

I dont know how resistant Vanadium is, it for sure doesnt send critical data, but screen size, hardware specs etc cant be not send without having no GPU acceleration and a letterboxed screen.

Would you be so kind to elaborate upon the bolded part? I’m simply unaware of the link between GPU acceleration and protection against fingerprinting.

Furthermore, just to be clear. I would like to retract my earlier statements that I’ve made regarding Vanadium and that were negative in nature. While there’s definitely truth in the fact that it does not provide fingerprinting protection (or spoofing) like what we find on Firefox (or Brave), but they have spoken out their ambitions and intentions to improve that. It’s simply that they haven’t put a lot of resources yet to the cause. And this is not for saving efforts or whatsoever, but rather because they intend to offer a more robust solution (eventually). We should also not disregard that, as is, GrapheneOS does offer some level of anonymity (in combination with best practices; i.e. VPN etc) merely by the virtue of only a select number of devices being supported by GrapheneOS and thus if two users are in relatively close proximity to one another and have their VPNs enabled and use the same device with GrapheneOS, then it might be hard for others to distinguish them from one another. Finally, at least regarding this topic, I don’t see them implementing letterboxing as we find on Firefox (as screen sizes are small anyways and only select number of screen sizes exist anyways, because only few devices are supported). Thus, as screen dimensions are not obfuscated, there’s less need to obfuscate the GPU in the first place.

mobile browsers have limited screens size and every SOC has a different GPU basically. So if you avoid hardware rendering, you would still need to pretend to be the smallest phone comparable, and pixel density etc. may still be different.

You may find some of my thoughts in the previous paragraph.

Ungoogled Chromium is a set of patches. These should totally be applied to Secureblue chromium, but currently it is saving effords by just using Fedora chromium and a few policies

Is it strictly beneficial for security? IIRC, privacy is (unfortunately) not regarded as a design goal for secureblue.

Btw, apologies if my sentences were more convoluted and confusing than they are otherwise. Thank you for your attention and consideration!

Those are just Firefox. Using some other routing doesnt improve security.

Never said or implied they were. Security is achieved through

Tor Browser or Mullvad Browser in a disposable qube on Qubes OS

Tor and Mullvad are only for preferred for the sake of anonymity as every user runs the exact same config on the same type of network.

Vanadium might be degoogled and not send critical platform data, but it is not fingerprint resistant afaik.

Hmm, you might be right. TIL. Thank you! Somehow, I was having high expectations for it… *sigh*

On mobile, browsers cant really be that though.

Do you happen to know why that’s the case?

On Desktop there only is ungoogled Chromium which is a beginning. But especially secureblue doesnt use it for some reason.

If I recall correctly, ungoogled-chromium has (at least in the past) been slacking on security. Don’t know if that’s still a thing though.

Chromium is just horrible to use.

Hard agree, except for PWAs; those at least work on Chromium-based browsers.

But honestly, it’s just very unfortunate that the closest we have to an ungoogled, secure, private and anonymous web browser is particularly platform-locked; I’m indeed referring to Vanadium.

On the desktop side of things, it’s just a mess; at least in my opinion*. I guess our best bet would be like running Tor Browser or Mullvad Browser in a disposable qube on Qubes OS 🤣. Furthermore, it would have to be connected through their respective network of choice; be it Tor network (and/)or VPN. And, ideally, without additional configuration changes to blend in as much as possible. Which comes down to foregoing your favorite extensions and even not maximizing the app window.

*sigh*, such a drag…

Librewolf has a nice build pipeline, I created a PR to just support replacing the malloc, that would be the easiest and best solution.

That’s very neat! Hopefully it comes through!

Then fedora firefox and librewolf would allow that, only flathub firefox missing really. Replacing the malloc is a very unsupported case for flatpak though, as the apps should be OS-unspecific.

But even with the ability to replace malloc, isn’t Firefox still vastly inferior compared to Chromium if security is desired? Or are they actually operating in close proximity of each other in terms of security features?

Feel free to help me figure that stuff out.

Other commitments are too much right now. But thanks for the offer!

Librewolf has a nice build pipeline, there is a

Feels like you fell asleep while you were writing this and didn’t bother to finish it later on hahaha (or simply forgot).

Does Librewolf (RPM) work?

Have not tested it. I rely on the flatpak.

I only know that Chromium browsers use userns or setuid namespaces to isolate tabs. This is not allowed by the flatpak seccomp filter (applied for all apps) which is why bubblejail is a thing. But bubblejail is veeeeery alpha, portals, theming, running random binaries etc all broken or difficult.

Isn’t bubblejail mostly a frontend to bubblewrap? Therefore, is it perhaps possible that, if well-understood, reliance on bubblewrap instead should translate to a less buggy (but indeed harder) experience?

Flatpak Chromium browsers use zypak instead, which will have a weaker seccomp filter than the tab sandbox in Chromium (because flatpak apps do more than browser tabs and there is only a single filter for them all).

I’ve often heard that the flatpak Chromium browsers are (somehow) less secure, but never heard why that’s the case. Thank you for offering a very concise explanation on the matter!

My dream would be to build Firefox, Thunderbird and Torbrowser on COPR (or Github so the Fedora people dont kill me) with hardened configs.

WOW, that would be awesome! You’ve already found yourself a ‘client’/‘customer’ :P . And I’m sure that a lot of others would be interested as well.

Longer than on vanilla fedora, or longer than before on secureblue?

Yes. To be clear, it’s both longer than on vanilla Fedora Atomic and also longer than before on secureblue.

as did a lot of other people

Reminds me of this project, I wanted to wait until it stabilized…, but it never got that far 😅. But I hope its maintainer will join team secureblue, if they haven’t yet*.

He invests hours in that project, look at the “secureblue Chromium vs Vanadium” table its crazy.

For reference; WOW, we definitely can’t deny their commitment. I feel indebted. Perhaps I should support them 😅. Do you happen to know if there are any other channels besides Github to support them (and the project)?

override removed packages on these images can neither be added back nor resetted, an rpm-ostree bug/issue.

Isn’t that supposed to work with BlueBuild (or any custom image tooling)?

so I use Chromium which sucks a lot.

You’re strong! I’ve been weak and have (instead) resorted to Librewolf. Initially, I had chosen to stick to Chromium. But, at least for now, I have to use Thunderbird anyways. So, might as well continue the use of Librewolf in the mean time.

Also had my system not boot twice, because of shitty Lenovo firmware and then because of the iwlwifi firmware bug.

I’ve also experienced some issues recently with boot times taking a lot more time than previously. But I’ve since changed some kernel arguments and it has been better since.

At the beginning there was no flatpak support, then only with bubblewrap-suid which is controversial and podman is broken, luckily there are userns images now.

This is indeed big; I wouldn’t have been able to make the switch without the userns images.

The hack to use hardened_malloc on Flatpaks is also very nonstandard and electron apps do completely random things it seems (dont use electron, but its everywhere! Nextcloud, mullvadVPN, Signal, Element, …)

Thank you for your continued contributions and efforts that go into ever-improving secureblue!

Yeah, I saw that you had shared the https://blue-build.org/ website a few days prior. But, to me at least, the “Introducing BlueBuild” blogpost seemed more like proper announcement/introduction compared to the default website. And has only been published since 2024-02-25, so only after your post 😉.

Thank you for your elaborate answers!

Qubes OS has a very steep learning curve due to its difficult usability, so the answer would be “both”. I am willing to tackle and overcome, but I’m not ready to put in that work yet, if at all.

Qubes OS is definitely more involved than the average distro, so I can understand why you feel that way.

I have a really funny story regarding threat models. When I first got into privacy 2-3 years ago, I had the goal of getting as deep as I could (the “strictest threat model possible”) and work backwards to find out what I was willing to allow.

Hahaha 🤣, very relatable; I almost wanted to learn SELinux for hardening purposes. Thankfully, Qubes OS exists as my endgame, which deterred (most of) the motivation (and need) to comprehend SELinux in the first place.

I have a “subconscious” threat model. I have, over the past week, started working on answering the classic questions. I am trying to protect against “evil” corporations, and such, I must also protect myself against some low level government threats. My threat model “philosophy” is: I will not use a piece of software if it actively goes against me in terms of privacy. Windows, for example, is a pain to try to use while maintaining privacy.

We can work with that, though I kindly implore you to further work out your threat model. It will(/should) give you some peace of mind (or at least a security/privacy roadmap on which you can (slowly but steadily) work towards). If I would have to distill your philosophy, it would be something like “be protected from attacks targeted towards low(er) hanging fruit”. Would that be fair?

You are the third person to recommend SecureBlue (I’ve been keeping track), and since it is a “Fedora Atomic spin” (Fedora Atomic as well as Atomic distros in general were also recommended three times each), I believe I will switch to it to see how it is.

Great choice! FWIW, I’ve also been on it for a couple of weeks now and I’ve really been enjoying it. Before, I had my own custom image that was built using the (legacy-)template from uBlue. I tried to harden it myself 😅, and I would argue I did and achieved some cool stuff with it. But, it’s very clear that my technical knowledge doesn’t even come close to that of secureblue’s maintainers. I just wish I had rebased earlier 😅.

By the way, I love the mention of GrapheneOS, since that will eventually (finances be blessed) be my main mobile OS

I definitely agree with that sentiment. Btw, FWIW, I know for a fact that at least one individual that’s associated with GrapheneOS has ‘contributed’ to secureblue.

I wish there was a true “Linux alternative to GrapheneOS”.

Hehe, without going into what that actually means and would entail, I agree 😜.

So I would like to ask a couple of questions:

Qubes OS (Tried it twice, not ready yet)

Is Qubes OS not ready yet for your intended workflow/usage? Or are you not ready to make the complete switch (yet)?

For me, it has been incredibly difficult to find a properly privacy oriented Linux distro that also has ease of use.

Unfortunately, in almost all cases, increased security/privacy is achieved through the loss of convenience. Therefore, you should ask yourself what the minimum level of security/privacy is that you absolutely require/need. How’s your threat model defined (if at all)?

My issue with Fedora is the lack of proper sandboxing, and it seems as though Qubes is the only one that really takes care in sandboxing apps.

I agree that there’s still a long road ahead until we have on Linux whatever is found on GrapheneOS or Qubes OS. I’m aware that you can technically utilize VMs on any distro, but the experience will not be as streamlined (nor as secure) as you may find on Qubes OS. But, Flatpak does offer some sandboxing. And while it may not be as powerful as you may want, and some apps may not utilize portals as they should. Still, it’s definitely worthwhile and perhaps the best we’ve got currently. Furthermore, bubblejail allows you to (relatively easily) utilize (some of) the technology that’s used to sandbox Flatpak apps for all your non-Flatpak apps. It can be found on Copr if you choose to stick to Fedora.

On that note, the maintainers of the aforementioned Copr package have built an interesting project for those that seek security-focused (or simply hardened) images of Fedora Atomic; (aptly named) secureblue. It’s still a relatively young project, but their innovations have definitely been noteworthy and it seems to have a bright future ahead.

While we’re in the vicinity of ‘hardened-for-you’-distros, we should mention Kicksecure. By contrast, this is a well-established distro by the people that also develop Whonix.

Without hearing your answers to my questions, I think these two are the primary candidates. Though sticking to Fedora ain’t a bad choice either.

so I run sudo nano /etc/default/grub

For improved security during file edits that require root access, it’s highly advised to use sudoedit (or sudo -e). This method is considered the standard practice to avoid the security pitfalls associated with directly invoking editors with sudo. To ensure the use of nano with sudoedit, simply set the VISUAL environment variable with export VISUAL=nano before running sudoedit . Alternatively, for a one-off command: VISUAL=nano sudoedit /path/to/file.

Please note that while sudoedit is a safer starting point, it’s not the only method available. Alternatives such as doas, doasedit, or leveraging polkit with pkexec can offer even more controlled and secure ways to manage file editing with elevated privileges. However, it’s perfectly acceptable to stick with sudoedit, as it’s a commonly trusted tool.

Be aware that direct usage of sudo nano or other editors is strongly discouraged. It bypasses important security mechanisms and can lead to inadvertent system-wide risks.

EDIT: changed VISUAL=nano sudoedit to VISUAL=nano sudoedit /path/to/file.

Thank you for your elaborate reply 😜!

The guide is mainly meant for exact this kind of new users, who are perfectly fine with either Fedora or Mint. I excluded edge-cases, like QubesOS, completely on purpose, as this should be consisting of only 2 (or so) distros with different DEs. This should make 80% of exactly those post redundant. If someone wants a “non-normal” distro, they can still of course feel free to ask.

I agree that it makes sense to start with tackling the problem in a way compliant with the 80/20 rule; i.e. 20 percent of the work to deal with 80 percent of the cases. I’m perhaps too much of a (wannabe) perfectionist/tryhard, which is why the process described in my previous post was a lot more involved and (perhaps) therefore more utopian/idealist than realistic. Perhaps I’ve even alluded to this a couple of times 😅.

I thought about using Sozi as a tool to achieve that. I have to research tho how to make a website first. My idea was to keep the exact structure of the chart, but when you zoom in a lot to the distro, you get the description.

Great idea! FWIW, perhaps an interactive map with pop-ups may be utilized to that effect. Though, there’s plenty to consider here and a lot of ways to do it justice. I trust in your capabilities to achieve that splendidly.

I see VanillaOS as a great competitor to Mint, especially for people who want something of a managed and simple experience, while also being capable to do normal PC stuff. I see VOS 2 as “stable” enough in just a few weeks, there’s mainly only some polishing and fixing in newer under-the-hood stuff, but the surface-stuff is already fine.

I haven’t installed the beta of its Orchid release yet. So, hopefully my gut feeling is just wrong. Ironically, the first time I installed a relatively immature version of an atomic distro (Fedora Kinoite, but like its first release (so Fedora 35 at the time)), it was a very bad experience and I rebased right away to Silverblue and haven’t look back since 🤣. Hopefully others will not be stung by VOS 2, like how I was stung by Kinoite.

It’s mainly about preference, if one likes a simple UI or prefers traditional workflows. How can I make that more clear?

By not naming any of the associated operating systems, but instead opt to distill their respective workflows in plain text. I’m very aware that this is pretty hard without spending way too many words on their descriptions. Therefore, perhaps it’s worth exploring if the ‘intended workflows’ of the different DEs might be (screen) captured and displayed as gifs. Obviously with the caveat that the ‘intended’ isn’t forced upon them and that they’re free to change them to better suit their needs.

First of all, I applaud your efforts. Making an all-encompassing guide/flowchart that is able to answer all kinds of needs that new users might have is hard and not done in just a few sittings. And it seems you’re willing to iterate a couple more times until you and the community are satisfied with the end result. That’s just awesome and highly commendable.

As for my personal critique, perhaps it’s noteworthy that I’m not entirely satisfied with the current setup. I think the following would align better with my personal convictions on how I would assist friends and/or family with these matters:

Having said all of that, whatever is mentioned above is a lot more involved than what you have currently. Therefore, I wouldn’t be surprised if you would deem most of it out of scope.

Moving on to the actual critique:

• While I (somewhat) understand why you’ve tried to tie one’s preferences in earlier used OSes to a potential desktop environment they might like, I do think that this might set new users up for false expectations. Therefore, I would propose to not even go there. If you want them to make a conscious choice on the desktop environment, then perhaps implore them to boot a live USB environment in which they can explore it themselves. The only important thing to note would be that in all cases customization is allowed and thus they shouldn’t necessarily abandon a DE for a minor issue as it’s most likely easily solvable.
• If this gets good (and it certainly has the potential), then only the flowchart itself will be shared while the accompanied text might be disregarded. In hopes of ensuring that others also read the accompanied text, consider to either (somehow) include the text in the image of the flowchart or include a link to the text and ensure it’s easily found and one is somehow able to easily access the text through the link. This might even require a shortened custom url that redirects to the text. The exact specifics are obviously up to you though.
• I can’t agree with the inclusion of both Pop!_OS and Vanilla OS. Don’t get me wrong, the potential is absolutely there. But both are currently in a major overhaul and need at least one or two proper releases to mature. Expecting new users to either start with the ‘abandoned’ old release which they might have to abandon themselves when they move over to the (eventually) matured new release or start with (at best) beta software that may come with a lot more trouble than worthwhile is IMO irresponsible.
• I got a ton of smaller (personal) nitpicks, but most of those are related to scope and/or preconceived notions and therefore not worth mentioning here.