Skip to main content


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 (4 months ago)

Seirdy reshared this.

in reply to Seirdy

if any of my info is dated or wrong (particularly regarding WebRTC) please LMK and I’ll update if necessary.
This entry was edited (4 months ago)
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 (4 months ago)
in reply to Seirdy

You’ve probably seen me salivating over alternative engines like Servo and Weasyprint, but I’m years away from recommending switching to them.

It takes a lot to handle untrusted content, especially untrusted applications!

This entry was edited (4 months ago)
in reply to Seirdy

So if one disables JIT as a common-sense measure and Javascript in general except on whitelisted sites, would you consider those engines ready?
This entry was edited (4 months ago)
in reply to LisPi

@lispi314 something equivalent to the Tor Browser’s “safest” profile would make if better, but not adequate for most people. ideally it’d have something to handle certificate revocation and a faster-updating certificate bundle.
in reply to Seirdy

@lispi314 A secure profile for Chromium would help this issue (and make my life much harder, but it’s totally worth it).
in reply to Seirdy

I think part of the issue though is that some browsers will disagree on what minimum/basic security a secure profile involves.

Tor Browser gets rid of all the JIT features from "safer" and just disables all Javascript as safest. The others don't do nearly as well.

This entry was edited (4 months ago)
in reply to Seirdy

ideally it’d have something to handle certificate revocation


Oh that was real? Browsers don't honor revocation? I was hoping that was some weird nightmare I was half-remembering...

This entry was edited (4 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

@niconiconi @lispi314 Outright stripping support for OCSP from your TLS stack, as Google did to BoringSSL and Chromium, is 100% premature though. We should move away from OCSP only after the alternatives are enough.
in reply to Seirdy

@niconiconi I'm not sure I'm a fan of certificate lifetimes that start getting dangerously close to the downtimes people can have in areas with crumbling infrastructure.
in reply to LisPi

@lispi314 @niconiconi Incremental improvements reduce the odds of exploitation. Not all sites need to make this transition, and every little reduction reduces the odds of a bad cert being in circulation. At scale, this translates to a reduction in incidents.

Domains that can’t do short lifetimes can benefit from the now-less-crowded revocation lists.

in reply to Seirdy

TLDR: every week we shave off from the average certificate lifetime, the less revocation incidents occur. The less revocation we have to deal with, the simpler the problem becomes. This isn’t an all-or-nothing situation.
This entry was edited (4 months ago)
in reply to Seirdy

It's tragic to me that the KDE world gave us KHTML which became the basis for WebKit and later Blink, but now Blink is the only viable browser engine in Qt. 😒
in reply to R. L. Dane

@RL_Dane There’s basically nothing left that connects KHTML to Blink now, so it’s more like a complete pivot than an evolution.
in reply to Seirdy

KHTML itself hasn't changed, though, has it? It's still pure KHTML under the hood, and not just a nasty Blink hook like what's in the Qt libs, right?

Not that much of anything actually *uses* #KTHML (afaik)

in reply to R. L. Dane

@RL_Dane KHTML has been officially discontinued since last year so yeah you’d hope not
in reply to Lady Strawberries

@LadyStrawberries
Ah, that's a bummer. But Konqueror is still around.. it's it just hooked into blink now? :(
in reply to R. L. Dane

@RL_Dane it uses KDEWebKit now yeah, although I think they might not have removed KHTML support yet
in reply to Lady Strawberries

@LadyStrawberries @RL_Dane khtml has not been ported to KF6, IIRC (I might be wrong!). so current versions have no KHTML support. If you wrote such a port it’d support the option.
in reply to Seirdy

All distros I know of make QtWebEngine’s KF6 wrapper a dependency of Konqueror (I think it’s calls KWebEngine or something) and make it the default renderer.
This entry was edited (4 months ago)
in reply to Seirdy

D'ya think it's fine that the Jellyfin desktop app uses't assuming I trust my Jellyfin instance admins? Idk but we always had bugs w Jellyfin in-browser for some reasons but w the desktop app't works fine.
in reply to Seirdy

Ungoogled Chromium caveats

Sensitive content

in reply to Seirdy

re: Ungoogled Chromium caveats
People really use mDNS et al? it's the first thing i disable on my base images.
in reply to G

re: Ungoogled Chromium caveats
@gcb necessary for IP hiding on WebRTC
@G
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.
in reply to G

re: Ungoogled Chromium caveats
the policy change assumes proxied udp is an option. some people may not have NAT loopback. mdns is the most robust option here, and it’s already been part of chromium for longer than it was used for WebRTC privacy.