Comment by yjftsjthsd-h | Hacker News Reader

Comment by yjftsjthsd-h | Hacker News Reader

So I'm not against it in the general case, but there are some very specific tradeoffs being made here.

> The following are not in scope for this project:

> Anything related to increasing "privacy", especially when at odds with improving security

> Anything related to "degoogling"

Frankly, knowing nothing further, I'm a little concerned that degoogling would be necessary. Like, is that just because the system bakes in Chromium? How much of the user's privacy is this thing selling away in the name of "security"?

Then most of the changes described are basically reasonable-sounding (very much trading everything else away in the name of security, but fine so long as the user knows what they're doing), but then there's this:

> Disabling unprivileged user namespaces

> Replacing bubblewrap with bubblewrap-suid so flatpak can be used without unprivileged user namespaces

And that's... again, I'm not going to say wrong, but it's a very specific tradeoff to decide that you trust bubblewrap more than the kernel. It's a plausibly-sensible trade, given the relative number of CVEs in bubblewrap with suid and linux's unprivileged user namespaces, but I'm not sure it sits well with me.

And finally, at a slightly more meta-level: Why should I trust this? It's an unofficial respin by an anonymous user; why would a user trust it?

I'm a little concerned that degoogling would be necessary.

I don't follow. The readme specifically says it's not in scope.

How much of the user's privacy is this thing selling away in the name of "security"?

Nothing more or less than upstream fedora. The point of putting that in there is to make it so we don't get people opening issues to ask us to switch to Brave or what have you.

tradeoff

Yes, it's a tradeoff and it's made clear in the readme that we're doing this.

Why should I trust this? It's an unofficial respin by an anonymous user; why would a user trust it?

I would have the same question :)

As I said in another comment: All of the CICD is completely open and transparent. You can read through the github actions logs and build config to verify everything for yourself if you want.

As a follow up to this, given that bubblewrap-suid without userns vs bubblewrap with userns is a tradeoff, I could make it so both variants are published. This would give users choice between the two and be less opinionated. If this is wanted please open an issue for it and I'll add it.

> I don't follow. The readme specifically says it's not in scope.

Let me rephrase: What is your distro doing that would make someone want to degoogle it?

What is your distro doing that would make someone want to degoogle it?

Certain users have expressed a preference towards Brave instead of Chromium because in their view Brave's "degoogling" of chromium is preferable. That line is in the readme to clarify that this is not a concern for the project and not in scope.

If that's what you mean, I would strongly suggest just saying that in the readme

Just changed it. Thanks for the feedback!

"degoogling" is nice in theory but I've rarely seen it done well in practice. There are either severe UX tradeoffs, or security pitfalls where maintainers mess with configs they don't actually understand.

Having not looked at this project in detail, perhaps it suffers the same fate regardless, but I do find their classification of it as a non-goal to be broadly reassuring.

"Not talking to google" might be more important to some people, and perhaps you're one of those people, so it's good that they're clear about priorities.

> "degoogling" is nice in theory but I've rarely seen it done well in practice.

Install Kali. There - unless you count Firefox - you have a viable 'degoogled' desktop.

> "degoogling" is nice in theory but I've rarely seen it done well in practice. There are either severe UX tradeoffs, or security pitfalls where maintainers mess with configs they don't actually understand.

As heuristics go that's how I feel about many "security" respins

I think there are some default libraries that support using Google Drive for backups, calendar, and email, among other things? TBH, I'd be surprised if those were in scope.

Reply on news.ycombinator.com