Is secureblue really more secure if browsers have to be installed in flatpaks?

I think that’s entirely reasonable, but I don’t think you’d try to solve that by wearing nondescript clothing. You’d appeal to society/the law to take action against that person following you around. Wearing nondescript clothing might make their job harder, but you’d have no way of knowing the extent to which you stopped them, and you wouldn’t stop the practice in general.

The same broadly applies here. Acting otherwise leads to chasing design patterns that lack a mechanism to falsify their effectiveness on the “output side” (i.e. whether or not they really prevent a profile from being built), and then pushing these patterns via individual behavior changes. Public policy change is a precondition to making these measures falsifiable, by at a minimum giving us visibility into what’s happening on the “output side”.

That is to say that the solution lies in public policy and building a coalition for collective change. The answer is to have the person who’s “following you around town” arrested, and if that’s not politically possible then at least requiring them to disclose information they have about you so you can determine whether or not “changing your clothes” is effective. One legislative starting point that would be highly useful would be requiring any company that profiles users to make user profiles available to the user upon request. This would at least allow us to have a concrete mechanism by which to falsify anti-fingerprinting claims and test them against each other concretely.

As far as I’m aware (but please correct me if I’m wrong on this), this is already required by California CCPA, so that could be an area where a long-term study could be designed for users in that jurisdiction, with some kind of instrumented accounts where the study author controls both the fingerprint surface and the identity.

One could of course argue that these anti-fingerprinting measures are worth doing even if their effectiveness on the “output” side isn’t falsifiable. This is all well and good if nothing is being sacrificed in the process, but too often it involves sacrificing security improvements (which are directly measurable and concretely falsifiable) for fingerprinting improvements that are abstract in their current unfalsifiability on the “output” side.

I greatly appreciate your perspective throughout this thread.

i see 0 privacy toggles being toggled.

trust me bro

Perhaps a moderator should separate this thread because this is rich discussion but there’s multiple different things being discussed. @moderators

You should be

As an additional data point, I found Brave (Origin, built from source) rather underwhelming. The ad blocker does a worse job than uBlock Origin for Firefox, in particular when it comes to cosmetic filtering. The benchmark performance (Speedometer 3.1) I recorded was the lowest among the three browsers that I tested (Brave, Firefox with clean profile, Chromium). And then there is the issue that Linux distros don’t package Brave, so unless you want to periodically rebuild from source, you need to trust Brave not to inject trackers, referral links, or other malware in the binaries they distribute (this has happened before).

The entire guide reads like a security masturbation theater

If you believe the guide has ways it can improved, I welcome them. The selection is based on merit, not what browser claims better privacy or is/isn’t run by a megacorp.
That said, privacy means nothing without security. I don’t get the “security masturbation theater” criticism.

and is very hostile to privacy projects, as evidenced by this thread.

Elaborate, what about this thread is indicative of this?

as if Chrome isn’t bloated.

Compared to Brave? Not really. Chrome is about as Vanilla as Chromium-based browsers get, Brave adds a lot more. For the stuff Brave disables, they add their own equivalent bloaty feature.

Abstract critique with 0 evidence.

What in particular?

“Attack surface” without proper analysis is just a buzzword.

It explicitly references the crypto stuff, but also their adblocker is also attack surface.

this doesn’t make any sense. Nobody forces you to install those extensions nor enable bloated Brave features.

No one is, but it’s used to point out a behavior of security neglect, as with bringing up the Flatpak verification point. And “bloat features” are on by default, otherwise they aren’t bloat.

0 evidence, citations, benchmarks.

What evidence do you believe is lacking?
Also what benchmarks? lol.

A person who wrote this guide is hostile to privacy and wrote this as if he wanted to provoke a reaction.

This is incorrect. As the author, it is designed to get people to be more conscious about their browsing decisions. I care deeply about privacy.

I have no alternative explanation to this Chrome recommendation.

It is the simplest browser, has the fastest update cycle, solid security, and the all the privacy intrusive features can be disabled by hand (via policy and flags). No other browser offers all 3 of these factors that is itself not designed for all 3. What about Chrome, when telemetry and such is disabled, is not private.

i see 0 privacy toggles being toggled.

I can link some, would 5 be sufficient?
#1, #2, #3, #4, #5

These are config entries, not individual toggles btw, the AI one for example (#2) is >10 toggles. Also this isn’t all of them, there are a lot with the PRIVACY tag.

What do you think of this recent opinion from the GrapheneOS team about Brave?

Brave is a Chromium-based browser with a very advanced filtering engine which doesn’t harm site isolation and avoids other weaknesses of extensions.

https://redlib.catsarch.com/r/GrapheneOS/comments/1unhtxu/initial_response_to_a_blog_post_claiming_to/

What do you think of this recent opinion from the GrapheneOS team about Brave?

It’s also accurate. It solves issues that extensions pose, that said it has its own issues. Namely the way it updates filterlists.
Like it is a direct upgrade over uBlock Origin, but has certain risks compared to uBO Lite.

@moderators I think we should close this thread.

OPs answer is quite simply a misunderstanding. Secureblue does not force requiring browsers to be installed via flatpak (and in fact says that you should not do that). I’ve been rocking SecureBlue with Trivalent + Mullvad Browser depending on the need, and at no point did I need to utilize flatpak for this process. Those utilizing immutable distros will need to get their hands dirty as its a different experience of a traditional distro.

I updated the guide with a new Librewolf section, let me know if it is inaccurate. I do have concerns that I mention in that section.

LW being based directly on arkenfox was true in the past

This was true before I got involved about half a year ago

Considering the brief mention of LW is all wrong, I would say everything should be reconsidered with the points made above.

I believe everything is corrected, thank you for bringing it to my attention.

Since Firefox refuses to ship even simple options like -ftrivial-auto-var-init=zero or -fwrapv and it hasn’t enabled STL hardening on Linux yet because of a slight performance hit, I wouldn’t say the bar is high.

Unfortunately so, like the opinion I have of Librewolf is positive compared to FF but base FF is so weak that I don’t think that yields much of a complement.

I also have some other hardening work that hasn’t been pushed yet, mainly CFI‑icall, since I’ve been focusing on improving our build system recently.

I would love to see that, CFI in Librewolf would put it leagues above FF. Even if just a subset. Have you looked into improving sandboxing at all? Like for example, enforcing W^X when JIT and webassembly are disabled?

I think we should close this thread.

Honestly, yeah. Way off-topic at this point.

I agree that the original question was a mistake (I have limited experience with immutable distros and had got it wrong).

However, it has become (IMO) a rather good, if a bit aggressive, debate over the trade offs of security vs privacy in browsers and in general. As well as helping fix some issues with outdated/incorrect parts of secureblue’s docs.

This could do with moving to another thread but I would be interested in seeing more detail on this as most of the people commenting seem to be very well informed on what they’re talking about and in many cases are actually developing it.

P.S. as a note while it’s going to be a while until they get there the developers of flatpak have said that flatpak next will fix the issue of flatpak’s breaking browser sandboxing and have a far greater level of control over permissions (though whether people actually use that is another question as many flatpak apps grant a tonne of unnecessary permissions).

While it’s certainly going to be a while till it’s out and I imagine an entire war will be fought over the currently proposed systemd dependency that should offer a pretty major upgrade to both browsers in particular and linux security more generally

Mistakes happen, in fact this forum is where we should be able to safely make them and learn from others :slight_smile: I also had a slew of questions about SecureBlue, and likely basic immutable distro questions, which RoyalOughtness had very patiently and kindly answered.

I’ll bite.

Honestly, I believe a lot of heat arises when people make security choices at the cost of privacy. I believe RO’s opinions comes with a lot of technical expertise in security, while say any1’s opinion comes from optimizations towards thread models focused on surveillance capitalism (I assuming this one). We should have people saying “anti-fingerprinting is great, now prove whats done is actually a meaningful tradeoff”.

I would honestly argue that SecureBlue is the most reasonable intersection of privacy 1st and security 2nd, as having Linux be a first priority is a big privacy respecting choice.

But I believe recommending Trivalent (or Chromium) over Firefox is definitely reasonable. I’ve actually taken the motto of using different browsers for different things.

  1. Logging into anything? Trivalent
  2. Anonymous browsing or research? Mullvad Browser

I believe there are 2 issues here, finger-printing, and cross-site fingerpriting (i.e. Google Analytics cross sites). I think the most meaningful choice here is to use Trivalent + multiple profiles for each logged in account. This prevents trackers for going across multiple sites, and you don’t need to delete cookies on everything. Doing this all within a VPN I believe solves significant surveillance capital concerns while maintain security for things that require authentication.

Agreed, I would also note for those interested that the whonix project exists which wraps the tor browser in a VM, separates the networking into another VM and then adds a few more anti fingerprinting stuff on there (e.g. measures to prevent you being fingerprinted via your typing pattern).

If you don’t mind a bit of faff to set it up and run it (and the overhead of running a VM) massively increases the security of tor by almost completely isolating it from the host system

As well as helping fix some issues with outdated/incorrect parts of secureblue’s docs.

Slight correction here. That wasn’t secureblue’s documentation, that is my own guide entirely separate from the secureblue project.

Tor

Also correct, I was assuming non tor usage, otherwise Mullvad Browser has no reason to exist.