Ungoogled Chromium caveats

In the wake of a certain ad-funded browser company bundling adtech into its browser :firefox: yet again, some people have been recommending Ungoogled-Chromium (UGC). I think it’s fine to recommend UGC with caveats, such as the fact that it disables component updates that include:

  • Certificate revocation. Chromium uses downloaded CRLSets for revocation; it does not support OCSP.
  • Out of band security patches. When browser components have exploits in the wild, they need to be patched ASAP; updating billions of installations within time-frames measured in hours often means restartless out-of-band updates.
  • Out of band certificate bundle updates.

If you assume Google uses its component update server logs maliciously, you may wish to consider a fork that still offers component updates provided by a different party’s servers.

UGC disabled mDNS at one point. This exposed local IP addresses over WebRTC for years, but they seem to have shipped a fix in May 2023 to disable non-proxied UDP.

UGC also disables the Chrome Web Store in favor of installing extensions out of band. Make sure you regularly update your extensions installed out-of-band, since UGC won’t do it on its own. Some scripts and a special extension re-implement some of this functionality.

Overall, UGC is still safer than QtWebEngine despite making heavy compromises to security for privacy (though I can’t see how either benefited from disabling mDNS: I’m not aware of threat models under which revealing a local IP to every application is preferable to revealing it to just Google). Running UGC is fine if you understand these trade-offs and have accounted for them. I use it in headless mode to run accessibility and performance tests.


Originally posted on seirdy.one: See Original (POSSE). #Chromium #Chrome

This entry was edited (8 months ago)

Seirdy reshared this.

in reply to Seirdy

oh and I never recommend QtWebEngine-based browsers. No component updates and extremely behind on regular updates, almost never built with Chromium’s LLVM toolchain hardening, extra fingerprintable…the list goes on. QtWebEngine is great for rendering mostly-trusted webpages but is definitely not ready to be a fully capable browser.

Re. toolchain hardening: to be fair, distros often don’t build Chromium itself with its toolchain hardening and most replace vendored hardened dependencies with system libraries. Fedora and Arch do it well enough (they still make it use system libraries without LLVM hardening but otherwise build it right); older Fedora versions patched Chromium to build with GCC! :akko_wtf2:

This entry was edited (8 months ago)
in reply to LisPi

CRL vs OCSP vs OCSP Stapling vs OCSP Must-Staple. Everyone knows Steve Gibson is a highly unreliable source on infosec, but his old post about the certificate revocation problem is mostly accurate. grc.com/revocation/ocsp-must-s…
in reply to niconiconi

@niconiconi @lispi314 Google is pushing for lower lifetimes instead. Lifetimes under 10 days make OCSP obsolete; if enough certs do this revocation becomes a lot easier to manage.

Must-Staple is essentially a short-lived certificate that only certain clients benefit from. Hell, even curl doesn’t check revocation status by default.

I use and recommend must-staple but I also recognize that only a small minority of sites will adopt it, and the right solution is to gradually reduce cert lifetimes to reduce the amount of revoked certs in circulation and make CRLSets/CRLite/Let’s-Revoke easier to pull off.

in reply to Seirdy

re: Ungoogled Chromium caveats
that thread made me skim the implemtation bugzilla.mozilla.org/show_bug.… and it is pseudo mdns supposed to only exist within the ice transport... too-clever over-engineered hacks like this WILL have bugs as soon as nobody is looking. should have been just a 2 line ip alias hack. freaking googlers astroturfing complexity for promotions.