On FF being more configurable…
Not that I think we identified any important setting the distribution or users must be able to change to make a good point for FF instead of chromium…
Ability to configure more could be possible through chrome (same for chromium?) policies?
On disabling of certain TLS versions or ciphers… If there is any security benefit if a distribution changed such default settings or if that was any useful if users did that… Please create a new forum thread for that. Since that discussion is kinda independent from this. Preferably with authoritative sources, experts explaining any threat model where this would lead to attack surface reduction, safer connections or anything else.
This is derived from the context of the discussion. Because of the title of this forum thread. Which default browser to choose.
Chromium Browser for Kicksecure Discussions (not Whonix)
Then also the link https://www.whonix.org/wiki/Dev/Chromium is saying:
This page is a collection of notes, issues, criticism, advantages of Chromium. Development Considerations regarding default installation of Chromium in Kicksecure.
I should have added link to https://www.whonix.org/wiki/Dev/Kicksecure_Default_Browser earlier or made that more clear.
Related, for most part unsolvable rabbit hole:
Selecting Secure Packages from packages.debian.org
With all due respect for all the work Debian people are doing, the maintenance of the Debian chromium package seems currently less than stellar.
Upstream Chrome (assuming same or similar for chromium, can’t easily find chromium stable release channel / versions) stable version is
86.0.4240. Debian Chromium version in Debian stable/testing/unstable is
83.0.4103.116 and Debian unstable has
84.0.4147. There is a good overview here:
Not all issues in that list may be critical. Some issues could be considered minor. For example:
CVE-2020-15959: Insufficient policy enforcement in networking in Google Chrome prior to 85.0.4183.102 allowed an attacker who convinced the user to enable logging to obtain potentially sensitive information from process memory via social engineering.
But others sounds more severe:
CVE-2020-15960: Heap buffer overflow in storage in Google Chrome prior to 85.0.4183.121 allowed a remote attacker to potentially perform out of bounds memory access via a crafted HTML page.
CVE-2020-6537: Type confusion in V8 in Google Chrome prior to 84.0.4147.105 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page.
An even better overview of the Debian chromium package showing which CVEs are currently shown as vulnerable:
Debian’s firefox-esr package has no such mentions:
But I guess @madaidan can pull out a reference showing how firefox-esr just means most security fixes are ignored and never back ported thereby relativize this?
So we have multiple different contests.
- A) upstream Firefox vs upstream Chromium
- B) Debian firefox-esr package vs Debian Chromium package
upstream Firefox vs upstream Chrome (irrelevant since Chrome isn’t fully Open Source)
Who’s the winner of each contest?
A) upstream Firefox vs upstream Chromium: Winner is Chromium.
B) Debian firefox-esr package vs Debian Chromium package?
Another option in theory for Kicksecure might be downloading packages for Debian from a another source (such as for example if Chromium provided these). But it doesn’t look as if these exist.
The chromium stable release channel links to, well, chrome. Not helpful.
There might be third parties providing alternative chromium packages. I’ve also seen download scripts before for chromium (similar to tb-updater) (non-package version). Or perhaps we would have to rely in a chromium (such as ungoogled-chromium if they did provide Debian
buster) packages or any other chromium fork project?
Even having both apparmor and bubblewrap profiles for Firefox wouldn’t speak for Firefox in favor of Chromium since it comes with its own sandbox. It’s an important thing too but could be implemented on top as bonus at any later time.